From report at bugs.python.org  Wed Jul  1 00:13:30 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jul 2020 04:13:30 +0000
Subject: [issue19335] codeop misclassifies incomplete code with 'nonlocal'
In-Reply-To: <1382373000.68.0.189461007664.issue19335@psf.upfronthosting.co.za>
Message-ID: <1593576810.13.0.162916716917.issue19335@roundup.psfhosted.org>


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

I reread Nick's comment "the C level loop simply blocks on stdin, waiting until the parser spits out a complete AST."  I interpret that now as meaning that the REPL compiles user code only once per statement, which IDLE and code.InteractiveInterpreter compile a statement once per line, which codeop expands to 3 compiles in an attempt to determine whether more is needed.  This can all be considered to be a hack, so adding 1 more does not bother me now.

(Side note: if the first compile succeeds in producing a code object, it is unconditionally returned after the additional compiles, so they seem like a waste.)

I looked at a git blame listing for codeop.  It was extracted from code by Guido in 1998 so that Jython (JPython) could replace compile_command.  It was not revised after the addition of nonlocal broke it.

I traced the flow of calls from when a user hits <Enter> in the entry area to the call of compile, and of the returns back.  The attached idle-shell-compile.txt records what I found.  Of particular interest to me:

1. IDLE strips trailing ' 's, '\t's, and 1 '\n' from user input before sending it to be compiled. (This goes back to the original IDLE commit in 2000.) So there is a trailing '\n' only when the user has hit '<Enter>' twice to complete a compound statement.  It would solve this issue *for IDLE* to only print the nonlocal error message when there is a trailing '\n'.  I am willing to give up the special casing needed to get 'def a():\n  nonlocal c' (no double <Enter>, no trailing '\n') to raise immediately.

Nothing in code says that it expects source to be stripped as IDLE does.  The reason for the latter might just be to get rid of the 'smart indent' that will precede the first Enter, and possibly anything the user adds before the second.  

2. compile is passed the undocumented flag PyCF_DONT_IMPLY_DEDENT = 0x200.  Can anyone explain the full intent?  I found this difference.

>>> compile("def f():\n  nonlocal c", '', 'single')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 2
SyntaxError: no binding for nonlocal 'c' found

# Same code, flag added, different message.
>>> compile("def f():\n  nonlocal c", '', 'single', 0x200)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 2
    nonlocal c
             ^
SyntaxError: unexpected EOF while parsing

# Add '\n' and message is same as without flag.
>>> compile("def f():\n  nonlocal c\n", '', 'single', 0x200)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 2
SyntaxError: no binding for nonlocal 'c' found

To use the message difference, the first compile-with-flag message would have to be saved for comparison, and the difference would only appear if source had no trailing '\n'.  We could make that be true, or we could wait until another user of codeop complains.

----------
Added file: https://bugs.python.org/file49282/idle-shell-compile.txt

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

From report at bugs.python.org  Wed Jul  1 00:25:57 2020
From: report at bugs.python.org (Mario Gonzalez)
Date: Wed, 01 Jul 2020 04:25:57 +0000
Subject: [issue896330] pyconfig.h is not placed in --includedir
Message-ID: <1593577557.86.0.0680707730037.issue896330@roundup.psfhosted.org>


Mario Gonzalez <mario.croach at gmail.com> added the comment:

hey u, send mi a mail, u need my help
and i need u 
mario the last one
mario.croach at gmail.com

----------
nosy: +Mario Gonzalez

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

From report at bugs.python.org  Wed Jul  1 02:05:30 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jul 2020 06:05:30 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1593583530.58.0.0423855478091.issue41177@roundup.psfhosted.org>


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

This is a change in behaviour, so probably needs to be added to future versions only.

----------
nosy: +vinay.sajip
versions: +Python 3.10 -Python 3.7

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

From report at bugs.python.org  Wed Jul  1 02:12:33 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Jul 2020 06:12:33 +0000
Subject: [issue41169] socket.inet_pton raised when pass an IPv6 address like
 "[::]" to it
In-Reply-To: <1593525971.46.0.103341919582.issue41169@roundup.psfhosted.org>
Message-ID: <1593583953.73.0.683658177645.issue41169@roundup.psfhosted.org>


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

In your example you are binding to [::1]. That's suppose to work. Binding or connecting to [::] does not work for me on Linux:


>>> addr = '[::]', 8888
>>> s = socket.socket(socket.AF_INET6)
>>> s.bind(addr)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno -2] Name or service not known
>>> s.connect(addr)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno -2] Name or service not known

----------

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

From report at bugs.python.org  Wed Jul  1 02:58:32 2020
From: report at bugs.python.org (Yunfan Zhan)
Date: Wed, 01 Jul 2020 06:58:32 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
Message-ID: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>


New submission from Yunfan Zhan <yfzhan at sjtu.edu.cn>:

While `code.__new__` is being audited, using `marshal.loads` to create a code object will trigger no events. Therefore, either `marshal.load(s)` event itself should be audited, or `code.__new__` should be triggered when marshal type is TYPE_CODE.

Considering that importing from a pyc file also relys on unmarshalling code objects, and they have already been audited as `import`, I'm also wondering if auditing twice should be avoided for performance.

----------
messages: 372733
nosy: steve.dower, tkmk
priority: normal
severity: normal
status: open
title: marshal load bypass code.__new__ audit event
type: security
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul  1 03:38:29 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 01 Jul 2020 07:38:29 +0000
Subject: [issue41179] find_library on macOS Big Sur
In-Reply-To: <1593569457.74.0.77283115603.issue41179@roundup.psfhosted.org>
Message-ID: <1593589109.76.0.803457964585.issue41179@roundup.psfhosted.org>


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

We're tracking macOS 11 changes in Issue41100. That issue has a PRs from Apple for, amongst others, this issue.

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren
superseder:  -> Build failure on macOS 11 (beta)
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Jul  1 04:03:53 2020
From: report at bugs.python.org (James Barrett)
Date: Wed, 01 Jul 2020 08:03:53 +0000
Subject: [issue40782] AbstactEventLoop.run_in_executor is listed as an async
 method, but should actually return a Futrue
In-Reply-To: <1590507938.7.0.58927076005.issue40782@roundup.psfhosted.org>
Message-ID: <1593590633.48.0.853960621922.issue40782@roundup.psfhosted.org>


James Barrett <james.barrett at bbc.co.uk> added the comment:

Is there any further movement on this?

----------

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

From report at bugs.python.org  Wed Jul  1 04:27:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jul 2020 08:27:10 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1593592030.37.0.286621224958.issue41158@roundup.psfhosted.org>


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

No, it can be backported to 3.8 and 3.9 if you wish.

----------

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

From report at bugs.python.org  Wed Jul  1 04:33:49 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 01 Jul 2020 08:33:49 +0000
Subject: [issue36839] Support the buffer protocol in code objects
In-Reply-To: <1557258986.94.0.539165158195.issue36839@roundup.psfhosted.org>
Message-ID: <1593592429.56.0.456610300866.issue36839@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

After seeing people from a certain company defend a bizarre and 
broken stack with falsehoods, I apologize to Inada-san and now
assume that he had a similar experience.

----------
nosy: +skrah

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

From report at bugs.python.org  Wed Jul  1 04:44:06 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 01 Jul 2020 08:44:06 +0000
Subject: [issue36839] Support the buffer protocol in code objects
In-Reply-To: <1557258986.94.0.539165158195.issue36839@roundup.psfhosted.org>
Message-ID: <1593593046.4.0.146487699652.issue36839@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Though code objects do not concern me directly, as the author of
memoryview I now concur with Inada-san that we should not support
hacks in the Python code base that benefit a single company.

----------

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

From report at bugs.python.org  Wed Jul  1 05:17:26 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 01 Jul 2020 09:17:26 +0000
Subject: [issue36839] Support the buffer protocol in code objects
In-Reply-To: <1557258986.94.0.539165158195.issue36839@roundup.psfhosted.org>
Message-ID: <1593595046.5.0.635037963936.issue36839@roundup.psfhosted.org>


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

FWI, I wrote my idea in python-ideas mailing list.

https://mail.python.org/archives/list/python-ideas at python.org/message/VKBXY7KDI2OGESB7IPAMAIIHKR4TC7TQ/

----------

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

From report at bugs.python.org  Wed Jul  1 05:24:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 09:24:47 +0000
Subject: [issue36839] Support the buffer protocol in code objects
In-Reply-To: <1557258986.94.0.539165158195.issue36839@roundup.psfhosted.org>
Message-ID: <1593595487.06.0.21146818591.issue36839@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jul  1 06:14:17 2020
From: report at bugs.python.org (disconnect3d)
Date: Wed, 01 Jul 2020 10:14:17 +0000
Subject: [issue37495] socket.inet_aton parsing issue on some libc versions
In-Reply-To: <1562190874.32.0.352639947279.issue37495@roundup.psfhosted.org>
Message-ID: <1593598457.81.0.287256315037.issue37495@roundup.psfhosted.org>


disconnect3d <dominik.b.czarnota+python at gmail.com> added the comment:

Its a while since this has been reported. I think inet_aton_pton.py is fine, though, a commit adding it should explain why we do it this way.

@vstinner can you push this patch further or do you want me to do it?

----------

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

From report at bugs.python.org  Wed Jul  1 06:15:03 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 01 Jul 2020 10:15:03 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593549875.63.0.81357373837.issue41176@roundup.psfhosted.org>
Message-ID: <1593598503.4.0.814060158142.issue41176@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I agree it would be helpful to expose an explicit way of telling if the mainloop was running but am not sure about removing `WaitForMainloop` as it could very easily break existing programs.

If a program executes a tkinter method in a thread before the mainloop is executed, the method will wait because of the call to `WaitForMainloop`. In the example script this is done deliberately to demonstrate the behaviour but could be done accidentally if the main thread has to do something else before the mainloop (and after the thread has been created).

I think the changes (whatever is concluded we should do) would be considered an 'enhancement', which would not be backported to 3.9 and before (I believe 'behaviour' is generally used for logic errors).

I am very willing to help review a PR, however the people you really need to convince are Serhiy and/or Guilherme (I have added them to the nosy).

----------
nosy: +epaine, gpolo, serhiy.storchaka
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49283/waitmainloop.py

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

From report at bugs.python.org  Wed Jul  1 06:15:39 2020
From: report at bugs.python.org (disconnect3d)
Date: Wed, 01 Jul 2020 10:15:39 +0000
Subject: [issue37495] socket.inet_aton parsing issue on some libc versions
In-Reply-To: <1562190874.32.0.352639947279.issue37495@roundup.psfhosted.org>
Message-ID: <1593598539.72.0.320701565736.issue37495@roundup.psfhosted.org>


disconnect3d <dominik.b.czarnota+python at gmail.com> added the comment:

Regarding the exception case: seems like OSError, since that's what originally was done and we don't want to break users of this code.

----------

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

From report at bugs.python.org  Wed Jul  1 06:32:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 10:32:21 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
Message-ID: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>


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

Link Time Optimization (LTO) and Profile-Guided Optimization (PGO) have a major impact on Python performance: they make Python between 10% and 30% faster (coarse estimation).

Currently, macOS installers distributed on python.org are built with Clang 6.0 without LTO or PGO. I propose to enable LTO and PGO to make these binaries faster.

IMO we should build all new Python macOS installers with these optimizations.

Attached PR adds the flags.


Python 3.9.0b3 binary:

$ python3.9
Python 3.9.0b3 (v3.9.0b3:b484871ba7, Jun  9 2020, 16:05:25) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

configure options:

>>> import sysconfig; print(sysconfig.get_config_var('CONFIG_ARGS'))
'-C' '--enable-framework' '--enable-universalsdk=/' '--with-universal-archs=intel-64' '--with-computed-gotos' '--without-ensurepip' '--with-tcltk-includes=-I/tmp/_py/libraries/usr/local/include' '--with-tcltk-libs=-ltcl8.6 -ltk8.6' 'LDFLAGS=-g' 'CFLAGS=-g' 'CC=gcc'

Compiler flags:

>>> sysconfig.get_config_var('PY_CFLAGS') + sysconfig.get_config_var('PY_CFLAGS_NODIST')
'-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -g-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I/Users/sysadmin/build/v3.9.0b3/Include/internal'

Linker flags:

>>> sysconfig.get_config_var('PY_LDFLAGS') + sysconfig.get_config_var('PY_LDFLAGS_NODIST')
'-arch x86_64 -g'

----------
components: Build
messages: 372743
nosy: vstinner
priority: normal
severity: normal
status: open
title: [macOS] Build macOS installer with LTO and PGO optimizations
type: performance
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul  1 06:36:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 10:36:38 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593599798.85.0.412490602686.issue41181@roundup.psfhosted.org>


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

The performance issue was noticed by Raymond Hettinger who ran a microbenchmark on tuplegetter_descr_get(), comparison between Python 3.8 and Python 3.9:

https://mail.python.org/archives/list/python-dev at python.org/message/Q3YHYIKNUQH34FDEJRSLUP2MTYELFWY3/

INADA-san confirms that the performance regression was introduced by the commit 45ec5b99aefa54552947049086e87ec01bc2fc9a (bpo-40170) which changes PyType_HasFeature() implementation to always call PyType_GetFlags() as a function rather than reading directly the PyTypeObject.tp_flags member.

https://mail.python.org/archives/list/python-dev at python.org/message/FOKJXG2SYMXCHYPGUZWVYMHLDR42BYFB/


On Fedora 32, there is no performance difference because binaries are built with GCC using LTO and PGO: the PyType_GetFlags() function call is inlined by GCC 10.


I built Python on macOS with clang 11.0.3 on macOS 10.15.4, and I confirm that LTO+PGO allows to inline the PyType_GetFlags() function call in tuplegetter_descr_get().

Using "./configure && make":
---
$ lldb ./python.exe
(lldb) disassemble --name tuplegetter_descr_get
(...)
python.exe[0x1001c46ad] <+29>:  callq  0x10009c720               ; PyType_GetFlags at typeobject.c:2338
python.exe[0x1001c46b2] <+34>:  testl  $0x4000000, %eax          ; imm = 0x4000000 
(...)
---

Using "./configure --with-lto --enable-optimizations && make":
---
$ lldb ./python.exe
(lldb) disassemble --name tuplegetter_descr_get
(...)
python.exe[0x1002a9542] <+18>:  movq   0x10(%rbx), %rdx
python.exe[0x1002a9546] <+22>:  movq   0x8(%rsi), %rax
python.exe[0x1002a954a] <+26>:  testb  $0x4, 0xab(%rax)
python.exe[0x1002a9551] <+33>:  je     0x1002a956f               ; <+63>
(...)
---

----------

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

From report at bugs.python.org  Wed Jul  1 06:38:05 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 01 Jul 2020 10:38:05 +0000
Subject: [issue36839] Support the buffer protocol in code objects
In-Reply-To: <1557258986.94.0.539165158195.issue36839@roundup.psfhosted.org>
Message-ID: <1593599885.49.0.187373085667.issue36839@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

For clarification, the incident I referred to is entirely unrelated to *this* issue:  Of course Dino Viehland has been rational, friendly and competent.

I wanted to point out that people might have had a formative experience *elsewhere*.

----------

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

From report at bugs.python.org  Wed Jul  1 06:39:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 10:39:15 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593599955.88.0.0416070108919.issue41181@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jul  1 06:46:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 10:46:48 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593600408.09.0.735859330737.issue41181@roundup.psfhosted.org>


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


----------
components: +macOS
nosy: +inada.naoki, ned.deily, rhettinger, ronaldoussoren

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

From report at bugs.python.org  Wed Jul  1 07:08:19 2020
From: report at bugs.python.org (Abhijeet Kasurde)
Date: Wed, 01 Jul 2020 11:08:19 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
Message-ID: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>


New submission from Abhijeet Kasurde <akasurde at redhat.com>:

When DefaultSelector is used on VMware ESXi, it fails with 

>>> import selectors
>>> selector = selectors.DefaultSelector()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/build/mts/release/bora-4887370/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/selectors.py", line 390, in __init__
OSError: [Errno 38] Function not implemented

After debugging, I found that it is using Selector which is not implemented for ESXi kernel. 

Change DefaultSelector mechanism to use 'select' implementation to choose default selector.

----------
components: Library (Lib)
messages: 372746
nosy: akasurde
priority: normal
severity: normal
status: open
title: DefaultSelector fails to detect selector on VMware ESXi
versions: Python 3.5

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

From report at bugs.python.org  Wed Jul  1 07:10:21 2020
From: report at bugs.python.org (Abhijeet Kasurde)
Date: Wed, 01 Jul 2020 11:10:21 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1593601821.91.0.254479897449.issue41182@roundup.psfhosted.org>


Change by Abhijeet Kasurde <akasurde at redhat.com>:


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

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

From report at bugs.python.org  Wed Jul  1 07:10:41 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 01 Jul 2020 11:10:41 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593601841.69.0.672706715249.issue41181@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

The installer is built on Mac OS X 10.9 so that it is forward compatible with all OS X and macOS versions. We cannot depend on PGO and LTO for it unless we start building the installer on 10.15. We cannot do this currently as those installers would not work with older macOS and OS X versions.

Since the Mac is switching to Apple Silicon, the plan is to start building a separate macOS 11+ installer. *That* could use PGO and LTO.

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Wed Jul  1 07:25:50 2020
From: report at bugs.python.org (Cezary Wagner)
Date: Wed, 01 Jul 2020 11:25:50 +0000
Subject: [issue41106] os.scandir() Windows bug dir_entry.stat() not works on
 file during writing.
In-Reply-To: <1593017703.53.0.919415125728.issue41106@roundup.psfhosted.org>
Message-ID: <1593602750.9.0.546653869114.issue41106@roundup.psfhosted.org>


Cezary Wagner <cezary.wagner at gmail.com> added the comment:

As far as I know os.stat() resets d.stat() maybe should be added some option to d.stat() to force update(). d.stat(nt_force_update=True).

I am not sure if os.path.getmtime() can reset d.stat().

os.stat() is 2x times slower than os.path.getmtime() and os.path.getmtime is 16x slower than d.stat(). MAJOR PROBLEM is PERFORMANCE of os.stat() since for directories with 1000 files it takes big number of seconds to read all stats - something wrong is here I think since Windows Explorer is doing it very fast.

So I can not use os.stat() ONLY and it complicates code since I need to use os.stat() after d.stat() if files is OLDER THAN because if I use os.stat() the most program time will be these calls.

Do you know which code makes such reset of d.stat()?

If there is not possible optimization of there is need DOCUMENTATION update because it is really hard to understand why it is not working under windows some REMARKS can help me and others.

I have still believe that some optimization is possible for Windows.

Maybe it can be force to read stat by os.scandir(force_scan_stat=True) so all directory entries will be have cached stats before d.stat() is called. It can be faster I think since less calls from Python and probably better Windows API for it and same for Linux.

I will study C code later if it is possible or write some snippet.

----------

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

From report at bugs.python.org  Wed Jul  1 07:41:45 2020
From: report at bugs.python.org (William Pickard)
Date: Wed, 01 Jul 2020 11:41:45 +0000
Subject: [issue41153] [easy Doc] "PyPreConfig_InitIsolatedConfig" and
 "PyPreConfig_InitPythonConfig" are given the opposite's documentation.
In-Reply-To: <1593375417.17.0.026489399384.issue41153@roundup.psfhosted.org>
Message-ID: <1593603705.56.0.930961533355.issue41153@roundup.psfhosted.org>


Change by William Pickard <lollol222gg at gmail.com>:


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

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

From report at bugs.python.org  Wed Jul  1 07:52:04 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Wed, 01 Jul 2020 11:52:04 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593598503.4.0.814060158142.issue41176@roundup.psfhosted.org>
Message-ID: <CADH6UF1sDjsoN=md72vpLpqrztizmZPKbWBGMKWt1pG8hh_VCw@mail.gmail.com>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

Removing `WaitForMainloop` would surely break some existing programs, but
that's why I suggested deprecation instead of just removing it suddenly. We
could issue a RuntimeWarning if `WaitForMainloop` actually waits and tell
the client to take responsibility for the race condition they created.
(They may have no idea! What if their delay unexpectedly increases to 1.2
seconds?) Whether or not waiting gets deprecated, it would make sense to
make the sleep behavior configurable instead of hardcoded. I'll include
something along those lines in my PR.

On Wed, Jul 1, 2020 at 6:15 AM E. Paine <report at bugs.python.org> wrote:

>
> E. Paine <paineelisha at gmail.com> added the comment:
>
> I agree it would be helpful to expose an explicit way of telling if the
> mainloop was running but am not sure about removing `WaitForMainloop` as it
> could very easily break existing programs.
>
> If a program executes a tkinter method in a thread before the mainloop is
> executed, the method will wait because of the call to `WaitForMainloop`. In
> the example script this is done deliberately to demonstrate the behaviour
> but could be done accidentally if the main thread has to do something else
> before the mainloop (and after the thread has been created).
>
> I think the changes (whatever is concluded we should do) would be
> considered an 'enhancement', which would not be backported to 3.9 and
> before (I believe 'behaviour' is generally used for logic errors).
>
> I am very willing to help review a PR, however the people you really need
> to convince are Serhiy and/or Guilherme (I have added them to the nosy).
>
> ----------
> nosy: +epaine, gpolo, serhiy.storchaka
> versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
> Added file: https://bugs.python.org/file49283/waitmainloop.py
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41176>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Jul  1 08:18:25 2020
From: report at bugs.python.org (Wator Sead)
Date: Wed, 01 Jul 2020 12:18:25 +0000
Subject: [issue41169] socket.inet_pton raised when pass an IPv6 address like
 "[::]" to it
In-Reply-To: <1593525971.46.0.103341919582.issue41169@roundup.psfhosted.org>
Message-ID: <1593605905.92.0.769280512095.issue41169@roundup.psfhosted.org>


Wator Sead <seahoh at gmail.com> added the comment:

[::] can be bound, but the resoult is [::1], you must use this address to connect. Excuse me, are you a developer of the Python?

>>> import socket
>>> ls = socket.socket(socket.AF_INET6)
>>> cs = socket.socket(socket.AF_INET6)
>>> ls.bind(('[::]', 888))  # no raise
>>> ls.listen(1)
>>> cs.connect(('[::1]', 888))  # no raise

----------

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

From report at bugs.python.org  Wed Jul  1 08:29:58 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Jul 2020 12:29:58 +0000
Subject: [issue41169] socket.inet_pton raised when pass an IPv6 address like
 "[::]" to it
In-Reply-To: <1593525971.46.0.103341919582.issue41169@roundup.psfhosted.org>
Message-ID: <1593606598.39.0.222201715713.issue41169@roundup.psfhosted.org>


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

The behavior of sockets depends on platform and implementation details of OS and libc. Binding to ('[::]', 888) does not work for me on Linux. It might work on other problems. The majority of functions and methods in the socket module are thin wrappers around low-level OS features. 

>>> import socket
>>> import sys
>>> sys.version
'3.8.3 (default, May 29 2020, 00:00:00) \n[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)]'
>>> sys.platform
'linux'
>>> s = socket.socket(socket.AF_INET6)
>>> s.bind(('[::]', 888))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno -2] Name or service not known

----------

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

From report at bugs.python.org  Wed Jul  1 08:33:44 2020
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 01 Jul 2020 12:33:44 +0000
Subject: [issue41170] Use strnlen instead of strlen when the size i known.
In-Reply-To: <1593565697.06.0.841082636792.issue41170@roundup.psfhosted.org>
Message-ID: <1593606824.43.0.428407651933.issue41170@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

strnlen() isn't standard C, but an exciting new function strnlen_s() is, as of C11.

https://en.cppreference.com/w/c/string/byte/strlen

(At this rate, we should be able to code CPython using that standard in about 2030.)

But!  I found a 2005 thread on /. talking about strnlen in MSVC.  So maybe it's there.  Though Microsoft has this funny habit of putting an underscore in front of C library functions that aren't standard, so maybe it's _strnlen().

----------
nosy: +larry

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

From report at bugs.python.org  Wed Jul  1 08:56:11 2020
From: report at bugs.python.org (Wator Sead)
Date: Wed, 01 Jul 2020 12:56:11 +0000
Subject: [issue41169] socket.inet_pton raised when pass an IPv6 address like
 "[::]" to it
In-Reply-To: <1593525971.46.0.103341919582.issue41169@roundup.psfhosted.org>
Message-ID: <1593608171.54.0.233639047189.issue41169@roundup.psfhosted.org>


Wator Sead <seahoh at gmail.com> added the comment:

Can you try bind "::".

My ask is "Can make a consistent behave via constraints it?".

----------

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

From report at bugs.python.org  Wed Jul  1 10:10:36 2020
From: report at bugs.python.org (Sumanth Ratna)
Date: Wed, 01 Jul 2020 14:10:36 +0000
Subject: [issue41179] find_library on macOS Big Sur
In-Reply-To: <1593569457.74.0.77283115603.issue41179@roundup.psfhosted.org>
Message-ID: <1593612636.07.0.657975318106.issue41179@roundup.psfhosted.org>


Sumanth Ratna <sumanthratna at gmail.com> added the comment:

I see; thanks for letting me know! I saw Issue41100 but I had assumed that it was only for build issues :)

Should I close this issue?

----------

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

From report at bugs.python.org  Wed Jul  1 10:35:46 2020
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 01 Jul 2020 14:35:46 +0000
Subject: [issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test
 failures
Message-ID: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>


New submission from Larry Hastings <larry at hastings.org>:

I'm testing 3.5.10rc1 on a freshly installed Linux (Pop!_OS 20.04), and I'm getting a lot of these test failures:

ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:2951)

Apparently the 2048 keys used in the tests are considered "too small" with brand-new builds of the SSL library.

Christian: you upgraded the test suite keys to 3072 bits back in 2018 (issue #34542), but didn't backport this as far as 3.5 because it was in security-fixes-only mode.  I experimented with taking your patch to 3.6 and applying it to 3.5, but 80% of the patches didn't apply cleanly.  Could you either backport this upgrade to 3.5 (I'll happily accept the PR), or advise me on how to otherwise mitigate the problem?  I don't really want to turn off all those tests.  Thanks!

----------
assignee: christian.heimes
components: Tests
messages: 372755
nosy: christian.heimes, larry
priority: high
severity: normal
stage: needs patch
status: open
title: Workaround or fix for SSL "EE_KEY_TOO_SMALL" test failures
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Jul  1 10:44:32 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Jul 2020 14:44:32 +0000
Subject: [issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593614672.18.0.730273717454.issue41183@roundup.psfhosted.org>


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

I'll look into it.

----------

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

From report at bugs.python.org  Wed Jul  1 10:57:59 2020
From: report at bugs.python.org (Brett Hannigan)
Date: Wed, 01 Jul 2020 14:57:59 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1593615479.36.0.28848263507.issue41177@roundup.psfhosted.org>


Change by Brett Hannigan <brett.hannigan at gmail.com>:


----------
versions:  -Python 3.10

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

From report at bugs.python.org  Wed Jul  1 11:02:02 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Jul 2020 15:02:02 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1593615722.55.0.392578173006.issue34542@roundup.psfhosted.org>


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


----------
pull_requests: +20406
pull_request: https://github.com/python/cpython/pull/21258

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

From report at bugs.python.org  Wed Jul  1 11:02:01 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Jul 2020 15:02:01 +0000
Subject: [issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593615721.95.0.899272726877.issue41183@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +20405
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21258

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

From report at bugs.python.org  Wed Jul  1 11:10:00 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jul 2020 15:10:00 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1593616200.99.0.592257030423.issue41158@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20407
pull_request: https://github.com/python/cpython/pull/21259

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

From report at bugs.python.org  Wed Jul  1 11:10:13 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jul 2020 15:10:13 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1593616213.42.0.0269211022556.issue41158@roundup.psfhosted.org>


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


----------
pull_requests: +20408
pull_request: https://github.com/python/cpython/pull/21260

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

From report at bugs.python.org  Wed Jul  1 11:24:15 2020
From: report at bugs.python.org (Anthropologist)
Date: Wed, 01 Jul 2020 15:24:15 +0000
Subject: [issue41184] Reconciling IDLE's Comment Out Region / Uncomment Region
 with PEP 8 guidelines for commenting
Message-ID: <1593617055.59.0.538237347639.issue41184@roundup.psfhosted.org>


New submission from Anthropologist <python at anthropo.org>:

IDLE's Comment Out Region formatting tool currently adds two octothorpe characters followed by no spaces.  The Uncomment Region tool removes up to 2 octothorpes but does not remove spaces. 

The Python Style Guide (PEP 8) specifies that: "An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space."

I propose reconciling these conflicting approaches to commenting out code, either by changing IDLE's behavior (i.e., instead of ##, Comment Out Region should insert # followed by a space, per PEP 8), or by amending the Python Style Guide to provide clear instructions about commenting out code, which is arguably a different use of comments than a single-line comment for the sake of explaining code. 

If the resolution involves changing IDLE's behavior, the Uncomment Region feature should also be changed to remove the space character after the octothorpe. As it currently stands, this feature fails to uncomment code that has been manually commented out following the guidelines in PEP 8.

----------
assignee: docs at python
components: Documentation, IDLE
messages: 372757
nosy: anthropologist, docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Reconciling IDLE's Comment Out Region / Uncomment Region with PEP 8 guidelines for commenting
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Jul  1 11:24:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 15:24:41 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593617081.57.0.82554937331.issue41181@roundup.psfhosted.org>


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

> We cannot depend on PGO and LTO for it unless we start building the installer on 10.15.

Clang 6.0 doesn't support LTO and PGO? Would you mind to elaborate?

----------

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

From report at bugs.python.org  Wed Jul  1 11:29:44 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jul 2020 15:29:44 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1593617384.19.0.186471735361.issue41158@roundup.psfhosted.org>


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


New changeset fe0175f5b50967aae90cb759a0d2d016fb745584 by Miss Islington (bot) in branch '3.9':
bpo-41158: IDLE: rewrite the code for handling file encoding (GH-21215)
https://github.com/python/cpython/commit/fe0175f5b50967aae90cb759a0d2d016fb745584


----------

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

From report at bugs.python.org  Wed Jul  1 11:32:35 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Wed, 01 Jul 2020 15:32:35 +0000
Subject: [issue41066] Update documentation for Pathlib
In-Reply-To: <1592756539.0.0.672795473082.issue41066@roundup.psfhosted.org>
Message-ID: <1593617555.26.0.799351343003.issue41066@roundup.psfhosted.org>


Change by Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com>:


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

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

From report at bugs.python.org  Wed Jul  1 12:04:14 2020
From: report at bugs.python.org (William Pickard)
Date: Wed, 01 Jul 2020 16:04:14 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1593619454.26.0.988448956471.issue39573@roundup.psfhosted.org>


Change by William Pickard <lollol222gg at gmail.com>:


----------
nosy: +WildCard65
nosy_count: 9.0 -> 10.0
pull_requests: +20410
pull_request: https://github.com/python/cpython/pull/21262

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

From report at bugs.python.org  Wed Jul  1 12:05:44 2020
From: report at bugs.python.org (Marco Barisione)
Date: Wed, 01 Jul 2020 16:05:44 +0000
Subject: [issue41185] lib2to3 generation of pickle files is racy
Message-ID: <1593619544.94.0.691494373061.issue41185@roundup.psfhosted.org>


New submission from Marco Barisione <marco at barisione.org>:

The generation of pickle files in load_grammar in lib2to3/pgen2/driver.py is racy as other processes may end up reading a half-written pickle file.

This is reproducible with the command line tool, but it's easier to reproduce by importing lib2to3. You just need different processes importing lib2to3 at the same time to make this happen, see the attached reproducer.

I tried with Python 3.9 for completeness and, while it happens there as well, it seems to be less frequent ony my computer than when using Python 3.6 (2% failure rate instead of 50% failure rate).

----------
components: 2to3 (2.x to 3.x conversion tool)
files: pool.py
messages: 372760
nosy: barisione
priority: normal
severity: normal
status: open
title: lib2to3 generation of pickle files is racy
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49284/pool.py

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

From report at bugs.python.org  Wed Jul  1 12:10:07 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Wed, 01 Jul 2020 16:10:07 +0000
Subject: [issue41007] test_importlib logs ResourceWarning:
 test_path.CommonTests.test_importing_module_as_side_effect()
In-Reply-To: <1592404400.93.0.826536668116.issue41007@roundup.psfhosted.org>
Message-ID: <1593619807.51.0.000272777173456.issue41007@roundup.psfhosted.org>


Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com> added the comment:

I can repro on  843c27765652e2322011fb3e5d88f4837de38c06  but I have tried this on latest master d0981e6 and I do not see the warning. 

can be closed?

----------
nosy: +thatiparthy

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

From report at bugs.python.org  Wed Jul  1 12:10:47 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Wed, 01 Jul 2020 16:10:47 +0000
Subject: [issue41007] test_importlib logs ResourceWarning:
 test_path.CommonTests.test_importing_module_as_side_effect()
In-Reply-To: <1592404400.93.0.826536668116.issue41007@roundup.psfhosted.org>
Message-ID: <1593619847.45.0.681320271377.issue41007@roundup.psfhosted.org>


Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com> added the comment:

(allhub) ?  cpython git:(master) ? ./python.exe -X tracemalloc=20 -m test  test_importlib -m test.test_importlib.test_path.CommonTests.test_importing_module_as_side_effect -v
== CPython 3.10.0a0 (heads/master:d0981e61a5, Jul 1 2020, 21:25:34) [Clang 11.0.3 (clang-1103.0.32.62)]
== macOS-10.15.5-x86_64-i386-64bit little-endian
== cwd: /Users/srini/workspace/consulting/cpython/build/test_python_1601?
== CPU count: 12
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 2.06 Run tests sequentially
0:00:00 load avg: 2.06 [1/1] test_importlib
test_importing_module_as_side_effect (test.test_importlib.test_path.CommonTests) ... ok

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

Ran 1 test in 0.061s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 6.5 sec
Tests result: SUCCESS

----------

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

From report at bugs.python.org  Wed Jul  1 12:18:23 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 01 Jul 2020 16:18:23 +0000
Subject: [issue41106] os.scandir() Windows bug dir_entry.stat() not works on
 file during writing.
In-Reply-To: <1593017703.53.0.919415125728.issue41106@roundup.psfhosted.org>
Message-ID: <1593620303.14.0.405890569517.issue41106@roundup.psfhosted.org>


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

> As far as I know os.stat() resets d.stat() maybe should be added 
> some option to d.stat() to force update(). d.stat(nt_force_update=True).

It depends on the filesystem. NTFS will update the directory entry as soon as the link is accessed by CreateFileW. But that's relatively expensive, and actually one of the more expensive steps in an os.stat call.

> I am not sure if os.path.getmtime() can reset d.stat().

genericpath.getmtime calls os.stat:

https://github.com/python/cpython/blob/d0981e61a5869c48e0a70a512967558391272a93/Lib/genericpath.py#L53

lexists, exists, getctime, getatime, getmtime, getsize, isdir, and isfile could be modified to call WinAPI GetFileAttributesExW [1], which is implemented via NtQueryFullAttributesFile [2], an optimized system call to get a file's network-open information. This can be significantly faster than the sequence of system calls that are required by os.stat. Note that this does not update the NTFS directory entry for the accessed link, unlike CreateFileW, but it does return updated information.

The GetFileAttributesExW result would be used if the call succeeds and the file isn't a reparse point. Otherwise fall back on os.stat (win32_xstat_impl). If passed an fd, try GetFileInformationByHandleEx to get the FileBasicInfo and FileStandardInfo, or use a single system call via NTAPI NtQueryInformationFile: FileNetworkOpenInformation, which is the same info that GetFileAttributesExW returns.

This could be implemented in C as nt._basic_stat(filename, follow_symlinks=True), where follow_symlinks means the expanded set of Windows name-surrogate reparse points. The C implementation would fall back on win32_xstat_impl. Note that a basic stat would not guarantee to return the following fields: st_ino, st_dev, and st_nlink. 

Alternatively, it could be implemented as a keyword-only basic=True option for os.stat, which would be ignored by POSIX. This way the high-level functions could continue to have a common implementation in genericpath.py.

[1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesexw
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwqueryfullattributesfile

----------

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

From report at bugs.python.org  Wed Jul  1 12:20:28 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 16:20:28 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593620428.77.0.23762477882.issue41181@roundup.psfhosted.org>


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

> Clang 6.0 doesn't support LTO and PGO?

No, it appears not.  And it's not an oversight that we don't use the these options.

As ?ukasz points out, for the current macOS installer variants we supply are designed to run on all Mac systems from macOS 10.9 on. To accomplish that safely, we build the Python binaries on macOS 10.9 system to ensure they will be compatible, in other words, we build on the oldest system support and rely on upward compatibility when running on newer systems. The other approach is to build on the newest systems available after adding runtime checks throughout the C code to test for the presence of newer features (i.e. runtime calls that have been added in an operating system release newer than the oldest one support).  While this ("weaklinking") can be a viable option, it's a lot more work to implement initially and then keep updated over each o/s release to avoid segfaults and other failures when users on older systems try to use newer features.  Eventually we would like to fully support weaklinking so that we could provide one installer variant for all supported o/s versions that has all features available at each o/s version, it's not a high priority item at the moment (for example, supporting the upcoming 11.0 Big Sur with Apple Silicon is) and the current practices have worked well for many years.

Keep in mind that the main goal of the python.org macOS installers is to provide a single installable binary that works correctly on a wide-range of macOS releases and hardware.  What we provide today works on all Macs capable of running macOS 10.9 or later.  In particular, it is *not* a goal to provide the most optimized configuration for a particular system.  In general, consider the range of hardware and operating system releases, that's not easy to do. I believe that the intended users for the python.org macOS pythons are (1) beginners (like in a teaching environment where ease of deployment and uniformity is key) and (2) third-party Mac applications developers who want an embeddable Python that will allow their applications to work on multiple levels of macOS. If you are looking for the highest performance for a particular use, like benchmarking, you should look elsewhere - like one of the third-party distributors who specialize in numeric Pythons - or build it yourself on your own system.

So, thanks for the suggestion but we won't be using it now. Sometime in the future, if and when we support weaklinking and/or use newer toolchains across the board we will look at adding and other optimizations.

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

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

From report at bugs.python.org  Wed Jul  1 12:27:01 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 16:27:01 +0000
Subject: [issue41179] find_library on macOS Big Sur
In-Reply-To: <1593569457.74.0.77283115603.issue41179@roundup.psfhosted.org>
Message-ID: <1593620821.55.0.571509625792.issue41179@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jul  1 12:37:10 2020
From: report at bugs.python.org (Bar Harel)
Date: Wed, 01 Jul 2020 16:37:10 +0000
Subject: [issue41186] distutils.version epoch compatibility
Message-ID: <1593621430.02.0.104429243352.issue41186@roundup.psfhosted.org>


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

Is distutils.version aware of the PEP440 epoch version modifier? I haven't seen any reference to this.

AFAIK pypa packaging does take it into consideration, but should the stdlib also care about it?

I would like to believe pip takes it into consideration but not sure if it uses distutils, or that setuptools have their own versioning scheme together with pkg_resources.

----------
components: Distutils
messages: 372765
nosy: bar.harel, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.version epoch compatibility
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul  1 12:40:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 16:40:00 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593621600.78.0.452357545445.issue41181@roundup.psfhosted.org>


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

>> Clang 6.0 doesn't support LTO and PGO?
> No, it appears not.

That's really surprising. I see LTO mentioned in LLVM 3.4 changelog for example:
https://releases.llvm.org/3.4/tools/clang/docs/ReleaseNotes.html#new-compiler-flags

Did you try to build Python with my PR? Which error message do you get? How can I try? I only own a macbook which runs a recent macOS version. Maybe I could try to get clang 6.0 on Linux.

If PGO is not available, just enabling LTO should already make Python faster significantly.

I understand why Python is built on macOS 10.9, and this issue and my PR doesn't change anything about that. I don't request to require newer CPU features or to require newer macOS API or syscall. LTO only changes how Python itself is built.

----------

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

From report at bugs.python.org  Wed Jul  1 12:43:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 16:43:28 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593621808.63.0.355386548113.issue41181@roundup.psfhosted.org>


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

If clang 6.0 is a dead end for LTO, another option is to build a recent clang version on macOS 10.9. If I manage to do that, would it sound like an acceptable solution? I don't expect any API/ABI issue just by changing the clang version. Upgrading clang should not change the semantics.

----------

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

From report at bugs.python.org  Wed Jul  1 12:43:49 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Wed, 01 Jul 2020 16:43:49 +0000
Subject: [issue41137] pdb uses the locale encoding for .pdbrc
In-Reply-To: <1593242595.67.0.594029276449.issue41137@roundup.psfhosted.org>
Message-ID: <1593621829.07.0.290181918805.issue41137@roundup.psfhosted.org>


Change by Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com>:


----------
keywords: +patch
nosy: +thatiparthy
nosy_count: 2.0 -> 3.0
pull_requests: +20411
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21263

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

From report at bugs.python.org  Wed Jul  1 12:48:27 2020
From: report at bugs.python.org (Bar Harel)
Date: Wed, 01 Jul 2020 16:48:27 +0000
Subject: [issue41186] distutils.version epoch compatibility
In-Reply-To: <1593621430.02.0.104429243352.issue41186@roundup.psfhosted.org>
Message-ID: <1593622107.74.0.592788578691.issue41186@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Actually, it looks like distutils days are quite over and pip itself uses setuptools with pypa packaging.

I'll take the initiative and close this.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jul  1 12:49:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jul 2020 16:49:25 +0000
Subject: [issue41187] Convert the _msi module to Argument Clinic
Message-ID: <1593622165.78.0.318018387297.issue41187@roundup.psfhosted.org>


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

The proposed PR converts the _msi module to Argument Clinic.

* Fixes deprecation warnings with the "u" format.
* Adds signatures.
* Adds meaningful docstrings.

----------
components: Argument Clinic, Windows
messages: 372769
nosy: larry, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Convert the _msi module to Argument Clinic
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Jul  1 12:51:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jul 2020 16:51:34 +0000
Subject: [issue41187] Convert the _msi module to Argument Clinic
In-Reply-To: <1593622165.78.0.318018387297.issue41187@roundup.psfhosted.org>
Message-ID: <1593622294.13.0.809480666112.issue41187@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

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

From report at bugs.python.org  Wed Jul  1 13:04:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 17:04:22 +0000
Subject: [issue41007] test_importlib logs ResourceWarning:
 test_path.CommonTests.test_importing_module_as_side_effect()
In-Reply-To: <1592404400.93.0.826536668116.issue41007@roundup.psfhosted.org>
Message-ID: <1593623062.64.0.274662268912.issue41007@roundup.psfhosted.org>


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

Alright, this issue was fixed by:

commit 2fb5f038f2a2e91a7293d62dfd5601e6eb500c55 (HEAD)
Author: Jason R. Coombs <jaraco at jaraco.com>
Date:   Mon Jun 29 16:59:22 2020 -0400

    bpo-40924: Ensure importlib.resources.path returns an extant path (GH-20857)

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

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

From report at bugs.python.org  Wed Jul  1 13:06:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 01 Jul 2020 17:06:00 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593623160.72.0.478399291852.issue41180@roundup.psfhosted.org>


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

I like using the existing event for unmarshalling code objects, assuming we have all the arguments available.

I'm not sure whether it's worth auditing all marshal.load() calls (just as we don't audit all pickle.load() calls). But depending on the code paths we may not have a choice.

Auditing the .pyc import twice (or more) is basically unavoidable, but it's not terrible anyway. When no hooks are set, it's negligible impact, and when someone adds a hook they are in control of how much work it does. Providing both events means they can choose to only handle one and still get the coverage.

Marking this as easy (C), since the hardest part is just going to be finding the right place to add the PySys_Audit call.

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

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

From report at bugs.python.org  Wed Jul  1 13:26:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jul 2020 17:26:41 +0000
Subject: [issue41184] Reconciling IDLE's Comment Out Region / Uncomment Region
 with PEP 8 guidelines for commenting
In-Reply-To: <1593617055.59.0.538237347639.issue41184@roundup.psfhosted.org>
Message-ID: <1593624401.75.0.716854407155.issue41184@roundup.psfhosted.org>


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

Guido, do you think PEP 8 should say anything about Comment-out Blocks?  It would not hurt, but one could say that since they are part of code development, and not usually a permanent part of committed code, they are out of scope, like choice of editor.  On the other hand, if they are left in stdlib code, I think that they should at least be distinct from text comments.  I presume that whoever added this feature to IDLE followed pre-existing practice.

Anthropolist: The comment-out feature predates my involvement with IDLE, but it is a useful feature for code maintenance.  Comment-out blocks are not inline comments.  They are more like comment blocks, which PEP 8 discusses just above inline comments.  However, the context natural language, default English, comments, so the guidelines do not apply.  Disabled code blocks have a different purpose and lifetime and in my opinion should be visually distinct.

If one manually comments out code with single hashes on the left margin, like so:
#def f():
#    def b():
#        nonlocal c
Uncomment Region will remove them.

If comment-out hashes are indented, like so
    ##def f():
    ##    def b():
    ##        nonlocal c
one can dedent and then uncomment.  Indeed, one can dedent, comment-out, and indent to add such to code.
---

I recursively grepped 3.9 /Lib for lines containing '##' and got 1596. Some are header or separator lines.  Some are emphasized text comment blocks (sometimes with '###').  Some xml and xmlrpc files have a convention of prefixing comment blocks with a line containing only '##'.

There are at least a few hundred commented-out code lines, perhaps half in idlelib, and mostly in tests.  Sometimes '##' is followed by a space, even within idlelib.  Sometimes '##' is indented instead of flush left.  

I suspect that these differences are editor related.  An editor aimed at experts, which is not IDLE, might have comment-out and uncomment options to adjust the number of #s, a following space or not, and an indent or not.

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

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

From report at bugs.python.org  Wed Jul  1 13:30:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 17:30:20 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1593624620.74.0.347130662845.issue40512@roundup.psfhosted.org>


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

> Update of the EXPERIMENTAL_ISOLATED_SUBINTERPRETERS status.

Also:

* _PyLong_Zero and _PyLong_One singletons are shared
* Py_None, Py_True and Py_False singletons are shared: bpo-39511 and PR 18301
* Static types like PyUnicode_Type and PyLong_Type are shared: see bpo-40077 and bpo-40601
* The dictionary of Unicode interned strings is shared: PR 20085
* context.c: _token_missing singleton is shared
* "struct _PyArg_Parser" generated by Argument Clinic is shared: see _PyArg_Fini()

Misc notes:

* init_interp_main(): if sys.warnoptions is not empty, "import warnings" is called to process these options, but not in subinterpreters: only in the main intepreter.
* _PyImport_FixupExtensionObject() contains code specific to the main interpreter. Maybe this function will not longer be needed once builtin extension modules will be converted to PEP 489 "multiphase initialization" API. I'm not sure.

----------

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

From report at bugs.python.org  Wed Jul  1 13:31:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 17:31:50 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1593624710.29.0.387044312024.issue40521@roundup.psfhosted.org>


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


----------
pull_requests: +20413
pull_request: https://github.com/python/cpython/pull/21265

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

From report at bugs.python.org  Wed Jul  1 13:40:01 2020
From: report at bugs.python.org (Lawrence D'Anna)
Date: Wed, 01 Jul 2020 17:40:01 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1593625201.97.0.752998798502.issue41100@roundup.psfhosted.org>


Change by Lawrence D'Anna <lawrence_danna at apple.com>:


----------
pull_requests: +20414
pull_request: https://github.com/python/cpython/pull/21266

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

From report at bugs.python.org  Wed Jul  1 13:43:00 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Jul 2020 17:43:00 +0000
Subject: [issue41184] Reconciling IDLE's Comment Out Region / Uncomment Region
 with PEP 8 guidelines for commenting
In-Reply-To: <1593617055.59.0.538237347639.issue41184@roundup.psfhosted.org>
Message-ID: <1593625380.91.0.825129695147.issue41184@roundup.psfhosted.org>


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

The IDLE feature should not change, for all the reasons Terry have.

I am quite done with changes to PEP in order to settle arguments, and I do not believe this convention needs mentioning in that PEP. Remember there is text in PEP 8 reminding readers to use your best judgment.

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

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

From report at bugs.python.org  Wed Jul  1 13:43:02 2020
From: report at bugs.python.org (William Pickard)
Date: Wed, 01 Jul 2020 17:43:02 +0000
Subject: [issue41188] Prepare CPython for opaque PyObject structure.
Message-ID: <1593625382.35.0.32807501167.issue41188@roundup.psfhosted.org>


New submission from William Pickard <lollol222gg at gmail.com>:

The goal of issue 39573 is to make "PyObject" and opaque structure in the limited API.

To do that, a few mandatory changes will be required to CPython in order to allow for seamless implementation.

Namely:
1) User types need to get away from directly referencing PyObject.
    - This can be done by adding a new variable to "PyTypeObject" who's value is an offset into the object's pointer to the type's internal structure.
        -- Example: 'PyType_Type.tp_obj_offset' would be the value of "sizeof(PyVarObject)".
        -- For custom types with another base: The value would be calculated from the base's "tp_obj_offset" + "tp_basicsize"

2) Create a linkable static library to facility method calls requiring internal implementation.
    - This static library will be implementation defined, IE: using internal methods specific to the runtime that created it.
    - Public facing methods will use generic names for example, "PyObject_GetType" will get the object's ob_type (or whatever the target runtime calls it).

----------
components: C API, Interpreter Core
messages: 372775
nosy: WildCard65, vstinner
priority: normal
severity: normal
status: open
title: Prepare CPython for opaque PyObject structure.
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Jul  1 13:45:18 2020
From: report at bugs.python.org (William Pickard)
Date: Wed, 01 Jul 2020 17:45:18 +0000
Subject: [issue41188] Prepare CPython for opaque PyObject structure.
In-Reply-To: <1593625382.35.0.32807501167.issue41188@roundup.psfhosted.org>
Message-ID: <1593625518.09.0.0834714963923.issue41188@roundup.psfhosted.org>


Change by William Pickard <lollol222gg at gmail.com>:


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

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

From report at bugs.python.org  Wed Jul  1 14:03:54 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Wed, 01 Jul 2020 18:03:54 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
Message-ID: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>


New submission from Iman Sharafodin <iman.sharafodin at gmail.com>:

Python 3.6 (June 27, 2020) (https://www.python.org/ftp/python/3.6.11/Python-3.6.11.tgz).

I found an exploitable segmentation fault in Python 3.6.11 (I validated that by using GDB's Exploitable plugin). Please find the attachment.

#0  0x0000000000b63bf4 in _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3667
#1  0x0000000000b5bc5b in PyEval_EvalFrameEx (throwflag=0, f=0x7ffff7f66c50) at Python/ceval.c:754
#2  _PyEval_EvalCodeWithName (_co=_co at entry=0x7ffff7ef5030, globals=globals at entry=0x7ffff7f62168, locals=locals at entry=0x7ffff7f62168, args=args at entry=0x0, argcount=argcount at entry=0, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4166
#3  0x0000000000b6100b in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=locals at entry=0x7ffff7f62168, globals=globals at entry=0x7ffff7f62168, _co=_co at entry=0x7ffff7ef5030) at Python/ceval.c:4187
#4  PyEval_EvalCode (co=co at entry=0x7ffff7ef5030, globals=globals at entry=0x7ffff7f62168, locals=locals at entry=0x7ffff7f62168) at Python/ceval.c:731

----------
files: ExploitableCrash.pyc
messages: 372776
nosy: Iman Sharafodin
priority: normal
severity: normal
status: open
title: An exploitable segmentation fault in _PyEval_EvalFrameDefault
versions: Python 3.6
Added file: https://bugs.python.org/file49285/ExploitableCrash.pyc

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

From report at bugs.python.org  Wed Jul  1 14:06:55 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jul 2020 18:06:55 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1593626815.21.0.338452725857.issue41158@roundup.psfhosted.org>


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


----------
pull_requests: +20416
pull_request: https://github.com/python/cpython/pull/21267

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

From report at bugs.python.org  Wed Jul  1 14:15:45 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 01 Jul 2020 18:15:45 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593627345.16.0.0504594964248.issue41189@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +ned.deily
type:  -> security

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

From report at bugs.python.org  Wed Jul  1 14:15:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jul 2020 18:15:29 +0000
Subject: [issue41190] msilib: SetProperty() accepts str,
 but GetProperty() returns bytes
Message-ID: <1593627329.36.0.902328564176.issue41190@roundup.psfhosted.org>


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

There is an inconsistency in the _msi.SummaryInformation class. Its method SetProperty() accepts str, but GetProperty() returns bytes (encoded with the Windows ANSI encoding).

Since os.fsencode()/os.fsdecode() now use UTF-8 encoding, it is not so easy to convert between bytes and str. Also, the encoding with the Windows ANSI encoding is lossy, so it may be that there is a loss in GetProperty().

----------
components: Windows
messages: 372777
nosy: paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: msilib: SetProperty() accepts str, but GetProperty() returns bytes
type: behavior

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

From report at bugs.python.org  Wed Jul  1 14:18:19 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 18:18:19 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593627499.57.0.520632437311.issue41181@roundup.psfhosted.org>


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

I should have made it clearer that we expect to release a new installer variant for macOS 11.6 Big Sur that supports both Intel and Apple Silicon architectures later this year (i.e. in several months) when Big Sur releases. It will be much easier to support newer optimizations in that variant.  We are in the process right now of getting builds to work on the developer previews and on developer hardware. We will look at optimizations for that variant then.

Please drop the idea of trying to change how we build on 10.9 (and, yes, we are perfectly capable of finding newer compilers to run on 10.9 but that's not the point - we *only* support building installers with standard Apple Developer Tool chains and with good reason); hacking on 10.9 is not worth it at this point.

----------

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

From report at bugs.python.org  Wed Jul  1 14:19:04 2020
From: report at bugs.python.org (Tianon)
Date: Wed, 01 Jul 2020 18:19:04 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1593627544.54.0.266233401678.issue38980@roundup.psfhosted.org>


Change by Tianon <admwiggin+pythonbugs at gmail.com>:


----------
nosy: +tianon

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

From report at bugs.python.org  Wed Jul  1 14:18:58 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 18:18:58 +0000
Subject: [issue41181] [macOS] Build macOS installer with LTO and PGO
 optimizations
In-Reply-To: <1593599541.73.0.325479735185.issue41181@roundup.psfhosted.org>
Message-ID: <1593627538.76.0.984973028677.issue41181@roundup.psfhosted.org>


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

er, "macOS 11.0 Big Sur" :)

----------

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

From report at bugs.python.org  Wed Jul  1 14:22:52 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jul 2020 18:22:52 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1593627772.72.0.54906657664.issue41158@roundup.psfhosted.org>


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


New changeset c3fa7534c7173d338880a1727f17795670518610 by Miss Islington (bot) in branch '3.8':
bpo-41158: IDLE: rewrite the code for handling file encoding (GH-21215)
https://github.com/python/cpython/commit/c3fa7534c7173d338880a1727f17795670518610


----------

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

From report at bugs.python.org  Wed Jul  1 14:38:35 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 18:38:35 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593628715.0.0.568285460209.issue41189@roundup.psfhosted.org>


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

Thank you for the report. Can you please supply the Python code that was translated into the .pyc file you supplied?  If there is some reason that you don't want to post it to this issue, you can email it to security at python.org.

----------

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

From report at bugs.python.org  Wed Jul  1 14:46:25 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Wed, 01 Jul 2020 18:46:25 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593629185.01.0.729051030219.issue41189@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

I created a Python file with 12 lines of code and then changed the bytecode to make Python crash (I was testing Python to find security related bugs). I can send the original file, do you need that?

----------

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

From report at bugs.python.org  Wed Jul  1 14:51:36 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 18:51:36 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593629496.58.0.740218676415.issue41189@roundup.psfhosted.org>


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

Sorry, if you modified the pyc file, that is undefined behavior. We make no guarantees that you can't crash the interpreter with arbitrary byte code.

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

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

From report at bugs.python.org  Wed Jul  1 14:53:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jul 2020 18:53:15 +0000
Subject: [issue41187] Convert the _msi module to Argument Clinic
In-Reply-To: <1593622165.78.0.318018387297.issue41187@roundup.psfhosted.org>
Message-ID: <1593629595.2.0.511620011223.issue41187@roundup.psfhosted.org>


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


New changeset 5d5c84ef78b19211671c2bfa68fe073485135eed by Serhiy Storchaka in branch 'master':
bpo-41187: Convert the _msi module to Argument Clinic (GH-21264)
https://github.com/python/cpython/commit/5d5c84ef78b19211671c2bfa68fe073485135eed


----------

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

From report at bugs.python.org  Wed Jul  1 14:56:24 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Wed, 01 Jul 2020 18:56:24 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593629784.52.0.509103546906.issue41189@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

It could be potential dangerous, for example some services might use Python Core to decompile pyc files and they could be hacked or some other services could run restricted pyc files for users but using this bug they can escape the sandbox and run the malicious code.

----------

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

From report at bugs.python.org  Wed Jul  1 15:01:56 2020
From: report at bugs.python.org (Hans Petter Jansson)
Date: Wed, 01 Jul 2020 19:01:56 +0000
Subject: [issue37999] No longer use implicit convertion to int with loss
In-Reply-To: <1567337044.72.0.119982097156.issue37999@roundup.psfhosted.org>
Message-ID: <1593630116.27.0.212998786506.issue37999@roundup.psfhosted.org>


Change by Hans Petter Jansson <hpj at cl.no>:


----------
nosy: +hpj
nosy_count: 2.0 -> 3.0
pull_requests: +20417
pull_request: https://github.com/python/cpython/pull/17536

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

From report at bugs.python.org  Wed Jul  1 15:02:47 2020
From: report at bugs.python.org (Lawrence D'Anna)
Date: Wed, 01 Jul 2020 19:02:47 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1593630167.39.0.371652739987.issue41100@roundup.psfhosted.org>


Change by Lawrence D'Anna <lawrence_danna at apple.com>:


----------
pull_requests: +20418
pull_request: https://github.com/python/cpython/pull/21268

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

From report at bugs.python.org  Wed Jul  1 15:06:23 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 01 Jul 2020 19:06:23 +0000
Subject: [issue41133] Insufficient description of cyclic garbage collector for
 C API
In-Reply-To: <1593210591.52.0.296051875695.issue41133@roundup.psfhosted.org>
Message-ID: <1593630383.01.0.0370767448195.issue41133@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah, pablogsal

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

From report at bugs.python.org  Wed Jul  1 15:14:49 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 01 Jul 2020 19:14:49 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1593630889.6.0.860154094102.issue41100@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Wed Jul  1 15:18:13 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 19:18:13 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593631093.63.0.730183797555.issue41189@roundup.psfhosted.org>


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

If users have unrestricted access to the interpreter, there are easier ways to crash Python than with modified byte code, for example, as is documented with ctypes. As noted on the Python Security Team web page (https://www.python.org/dev/security/): "If you can already execute Python code, there are far worse things you can do than provoke a use-after-free or an interpreter crash."

----------

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

From report at bugs.python.org  Wed Jul  1 15:26:39 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Wed, 01 Jul 2020 19:26:39 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593631599.38.0.211090007476.issue41189@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

You're right. But if someone uses the exact same code to decompile a pyc to a Python code, attacker doesn't have access to the interpreter and cannot even run the pyc file on the server, but the attacker can cause a crash and run the malicious exploit code. Anyway, my only goal was to help Python community (which I love it) to improve the code quality. Have a nice day.

----------

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

From report at bugs.python.org  Wed Jul  1 15:37:22 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jul 2020 19:37:22 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593632242.25.0.604036170524.issue41189@roundup.psfhosted.org>


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

> my only goal was to help Python community (which I love it) to improve the code quality

Thanks for trying to improve things, we do appreciate it!

The idea here is that to be able to exploit the crashing pyc file, you need to be able to run an arbitrary pyc file on the web service and to do that the attacker has to have access somehow to the interpreter. If the web service has a hole to allow that, many bad things are possible. That's true for many other languages and tools, too.  So it's just not worth worrying about being able to crash with a fuzzed pyc file since, if you can exploit that, you can exploit in much easier ways.

----------

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

From report at bugs.python.org  Wed Jul  1 15:48:18 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Wed, 01 Jul 2020 19:48:18 +0000
Subject: [issue41189] An exploitable segmentation fault in
 _PyEval_EvalFrameDefault
In-Reply-To: <1593626634.77.0.865849185728.issue41189@roundup.psfhosted.org>
Message-ID: <1593632898.65.0.0554680934076.issue41189@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

Thank you for the response.

----------

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

From report at bugs.python.org  Wed Jul  1 16:07:20 2020
From: report at bugs.python.org (Matthieu Dartiailh)
Date: Wed, 01 Jul 2020 20:07:20 +0000
Subject: [issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's
 new
Message-ID: <1593634040.83.0.8340731803.issue41191@roundup.psfhosted.org>


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

Looking at the What's new for Python 3.9 I noticed that there was no mention of PEP 573. The added functions are properly documented and should probably be mentioned in the What's new.

----------
assignee: docs at python
components: Documentation
messages: 372790
nosy: docs at python, mdartiailh
priority: normal
severity: normal
status: open
title: PyType_FromModuleAndSpec is not mentioned in 3.9 What's new
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul  1 16:42:43 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 01 Jul 2020 20:42:43 +0000
Subject: [issue41073] [C API] PyType_GetSlot() should accept static types
In-Reply-To: <1592815094.33.0.264745776024.issue41073@roundup.psfhosted.org>
Message-ID: <1593636163.75.0.898674226865.issue41073@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> If we extend PyType_GetSlot() to accept non-heaptype, we need find a way to judge the max slot of non-heaptype.

Static types can have some sub-slots structs but not others. A "max slot" will not help for types that have tp_as_mapping but not tp_as_number, for example.
You'll probably need some table like typeslots.inc to record which sub-slots struct each slot belongs to.

----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Wed Jul  1 16:48:14 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 01 Jul 2020 20:48:14 +0000
Subject: [issue41168] Lack of proper checking in PyObject_SetAttr leads to
 segmentation fault
In-Reply-To: <1593518684.95.0.149768712012.issue41168@roundup.psfhosted.org>
Message-ID: <1593636494.8.0.543585292361.issue41168@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

What kind of security-related issues do you mean? A .pyc file is code; it can do anything. Never run untrusted code, be it .py or .pyc.

See also: Lib/test/crashers/bogus_code_obj.py

----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Wed Jul  1 16:55:12 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 01 Jul 2020 20:55:12 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593636912.9.0.304418688138.issue41043@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Would it be worth it to add a "base" keyword argument to glob.glob?

----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Wed Jul  1 17:08:42 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jul 2020 21:08:42 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1593637722.45.0.441064136307.issue39385@roundup.psfhosted.org>


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


New changeset 6b34d7b51e33fcb21b8827d927474ce9ed1f605c by Kit Choi in branch 'master':
bpo-39385: Add an assertNoLogs context manager to unittest.TestCase (GH-18067)
https://github.com/python/cpython/commit/6b34d7b51e33fcb21b8827d927474ce9ed1f605c


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Wed Jul  1 17:09:42 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jul 2020 21:09:42 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1593637782.08.0.856093643249.issue39385@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

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

From report at bugs.python.org  Wed Jul  1 17:21:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 21:21:43 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1593638503.72.0.0667695820658.issue40521@roundup.psfhosted.org>


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


New changeset 90db4653ae37ef90754cfd2cd6ec6857b87a88e6 by Victor Stinner in branch 'master':
bpo-40521: Cleanup finalize_interp_types() (GH-21265)
https://github.com/python/cpython/commit/90db4653ae37ef90754cfd2cd6ec6857b87a88e6


----------

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

From report at bugs.python.org  Wed Jul  1 18:17:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 22:17:13 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593641833.08.0.00878019638552.issue1635741@roundup.psfhosted.org>


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


----------
pull_requests: +20419
pull_request: https://github.com/python/cpython/pull/21269

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

From report at bugs.python.org  Wed Jul  1 18:27:37 2020
From: report at bugs.python.org (Francis Herne)
Date: Wed, 01 Jul 2020 22:27:37 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1593642457.5.0.07301475161.issue39579@roundup.psfhosted.org>


Francis Herne <mail at flherne.uk> added the comment:

Note: this change causes a regression in kdev-python because our code was based on (and worked around) the long-standing previous behaviour; it produces broken results given the 'fixed' offset.

I shall have to write a patch with a version-check before our next stable release.

While the new behaviour is more logical, I'm not convinced that deliberate API breakage in a stable release - for something that's not a recent regression - was a good idea.

----------
nosy: +flherne

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

From report at bugs.python.org  Wed Jul  1 19:20:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 23:20:03 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593645603.71.0.288319214462.issue1635741@roundup.psfhosted.org>


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


New changeset 666ecfb0957a2fa0df5e2bd03804195de74bdfbf by Victor Stinner in branch 'master':
bpo-1635741: Release Unicode interned strings at exit (GH-21269)
https://github.com/python/cpython/commit/666ecfb0957a2fa0df5e2bd03804195de74bdfbf


----------

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

From report at bugs.python.org  Wed Jul  1 19:21:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jul 2020 23:21:21 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593645681.55.0.586362574371.issue1635741@roundup.psfhosted.org>


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


----------
pull_requests: +20420
pull_request: https://github.com/python/cpython/pull/21270

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

From report at bugs.python.org  Wed Jul  1 19:44:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Jul 2020 23:44:04 +0000
Subject: [issue41133] Insufficient description of cyclic garbage collector for
 C API
In-Reply-To: <1593210591.52.0.296051875695.issue41133@roundup.psfhosted.org>
Message-ID: <1593647044.39.0.311499309312.issue41133@roundup.psfhosted.org>


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

I agree with what Tim said. We also cannot foresee every possible bug of someone misusing the C API, and the garbage collector interacts with many systems of the VM, and having gigantic documentation has shown to be always detrimental. 

> I think it would be helpful to have something as troubleshooting information on the garbage collector. If you've got a bug in your C module,

"A bug in your C module" can be absolutely anything (even more things given that we are talking about C!). Many people also blame the GC immediately just because the crash happens during visitation when the bug already happened much before. I don't think that a "general debugging section" about the GC will be very as helpful as improving the clarity of the contract.

> For that matter, the documentation for tp_traverse doesn't mention that you have to call Py_VISIT on each object exactly as many times as references you hold to it; the phrasing sounds like it's fine so long as you call it at least once on any object you hold a reference to.

A note in the docs about this sounds reasonable as is well-scoped. If you want, you can do a PR and add me there and I will review it. Otherwise, I will try to put something together myself.

----------

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

From report at bugs.python.org  Wed Jul  1 20:19:06 2020
From: report at bugs.python.org (Francis Herne)
Date: Thu, 02 Jul 2020 00:19:06 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1593649146.92.0.62198885886.issue39579@roundup.psfhosted.org>


Francis Herne <mail at flherne.uk> added the comment:

Sorry, on further inspection it was the other AST range change https://bugs.python.org/issue39474 , not this one.

----------

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

From report at bugs.python.org  Wed Jul  1 22:22:48 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 02 Jul 2020 02:22:48 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1593656568.01.0.600900949635.issue41100@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

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

From report at bugs.python.org  Wed Jul  1 22:23:30 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 02 Jul 2020 02:23:30 +0000
Subject: [issue41137] pdb uses the locale encoding for .pdbrc
In-Reply-To: <1593242595.67.0.594029276449.issue41137@roundup.psfhosted.org>
Message-ID: <1593656610.48.0.757122816972.issue41137@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

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

From report at bugs.python.org  Wed Jul  1 23:24:08 2020
From: report at bugs.python.org (Yunfan Zhan)
Date: Thu, 02 Jul 2020 03:24:08 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593660248.55.0.870795922919.issue41180@roundup.psfhosted.org>


Change by Yunfan Zhan <yfzhan at sjtu.edu.cn>:


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

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

From report at bugs.python.org  Wed Jul  1 23:41:33 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 03:41:33 +0000
Subject: [issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task()
 must be removed in 3.9
In-Reply-To: <1592045282.09.0.91488246101.issue40967@roundup.psfhosted.org>
Message-ID: <1593661293.01.0.519337080021.issue40967@roundup.psfhosted.org>


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


New changeset 004e64e8059fe68a72890314673282f2e60d5ce1 by R?mi Lapeyre in branch 'master':
bpo-40967: Remove deprecated asyncio.Task.current_task() and asyncio.Task.all_tasks() (GH-20874)
https://github.com/python/cpython/commit/004e64e8059fe68a72890314673282f2e60d5ce1


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

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

From report at bugs.python.org  Wed Jul  1 23:41:47 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 03:41:47 +0000
Subject: [issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task()
 must be removed in 3.9
In-Reply-To: <1592045282.09.0.91488246101.issue40967@roundup.psfhosted.org>
Message-ID: <1593661307.21.0.58736425247.issue40967@roundup.psfhosted.org>


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


----------
pull_requests: +20422
pull_request: https://github.com/python/cpython/pull/21272

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

From report at bugs.python.org  Thu Jul  2 00:06:55 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 04:06:55 +0000
Subject: [issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task()
 must be removed in 3.9
In-Reply-To: <1592045282.09.0.91488246101.issue40967@roundup.psfhosted.org>
Message-ID: <1593662815.4.0.179107569142.issue40967@roundup.psfhosted.org>


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


New changeset df59293bf0d815fe37743025d639a63a78e0c771 by Miss Islington (bot) in branch '3.9':
bpo-40967: Remove deprecated asyncio.Task.current_task() and asyncio.Task.all_tasks() (GH-20874)
https://github.com/python/cpython/commit/df59293bf0d815fe37743025d639a63a78e0c771


----------

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

From report at bugs.python.org  Thu Jul  2 00:18:26 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 02 Jul 2020 04:18:26 +0000
Subject: [issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task()
 must be removed in 3.9
In-Reply-To: <1592045282.09.0.91488246101.issue40967@roundup.psfhosted.org>
Message-ID: <1593663506.99.0.66564229221.issue40967@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Thanks R?mi for working on this.

----------
priority: release blocker -> normal
stage: patch review -> commit review

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

From report at bugs.python.org  Thu Jul  2 00:38:46 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 04:38:46 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated since Python 3.3
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593664726.03.0.613756301952.issue41165@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jul  2 00:56:52 2020
From: report at bugs.python.org (SilentGhost)
Date: Thu, 02 Jul 2020 04:56:52 +0000
Subject: [issue41157] email.message_from_string() is unable to find the
 headers for the .msg files
In-Reply-To: <1593427866.61.0.334200042199.issue41157@roundup.psfhosted.org>
Message-ID: <1593665812.82.0.321419138676.issue41157@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


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

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

From report at bugs.python.org  Thu Jul  2 00:57:07 2020
From: report at bugs.python.org (SilentGhost)
Date: Thu, 02 Jul 2020 04:57:07 +0000
Subject: [issue41157] email.message_from_string() is unable to find the
 headers for the .msg files
In-Reply-To: <1593427866.61.0.334200042199.issue41157@roundup.psfhosted.org>
Message-ID: <1593665827.2.0.901002231016.issue41157@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)

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

From report at bugs.python.org  Thu Jul  2 02:18:45 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 06:18:45 +0000
Subject: [issue9424] Deprecate assertEquals, assertNotEquals, assert_,
 assertAlmostEquals, assertNotAlmostEquals
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1593670725.38.0.0500831529935.issue9424@roundup.psfhosted.org>


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

Can we remove these aliases in Python 3.10?
(See also #41165)

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Thu Jul  2 02:18:53 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 06:18:53 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated since Python 3.3
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593670733.85.0.260044472924.issue41165@roundup.psfhosted.org>


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

Unittest aliases are deprecated in #9424.
Can we remove them in Python 3.10?

----------

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

From report at bugs.python.org  Thu Jul  2 02:19:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 06:19:59 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593670799.25.0.557613053296.issue41043@roundup.psfhosted.org>


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

It may be not exactly what you meant, but see issue38144. This issue actually was opened after I looked how that feature can be used in the stdlib and found that most of uses of glob() are vulnerable.

----------

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

From report at bugs.python.org  Thu Jul  2 02:21:33 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 06:21:33 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated since Python 3.3
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593670893.73.0.778809678759.issue41165@roundup.psfhosted.org>


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


----------
keywords: +easy

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

From report at bugs.python.org  Thu Jul  2 02:23:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 06:23:08 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593670988.86.0.691419945907.issue41043@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +20424
pull_request: https://github.com/python/cpython/pull/21275

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

From report at bugs.python.org  Thu Jul  2 02:24:40 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 06:24:40 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated since Python 3.3
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593671080.59.0.57559258748.issue41165@roundup.psfhosted.org>


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


----------
pull_requests: +20425
pull_request: https://github.com/python/cpython/pull/21276

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

From report at bugs.python.org  Thu Jul  2 02:27:32 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Thu, 02 Jul 2020 06:27:32 +0000
Subject: [issue41192] Some audit events are undocumented
Message-ID: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>


New submission from Saiyang Gou <gousaiyang223 at gmail.com>:

Currently the following audit events are not documented on docs.python.org:

- _winapi.CreateFile
- _winapi.CreateJunction
- _winapi.CreateNamedPipe
- _winapi.CreatePipe
- _winapi.CreateProcess
- _winapi.OpenProcess
- _winapi.TerminateProcess
- ctypes.PyObj_FromPtr
- object.__getattr__
- object.__setattr__
- object.__delattr__
- function.__new__
- setopencodehook
- builtins.id
- os.walk
- os.fwalk
- pathlib.Path.glob
- pathlib.Path.rglob

I'm going to create a PR to add them to the documentation. However, for `_winapi` events and `ctypes.PyObj_FromPtr`, I cannot find corresponding sections in the documentation to put the `audit-event` rst directive. How should we document them and make them show up in the audit events table?

----------
assignee: docs at python
components: Documentation
messages: 372806
nosy: docs at python, gousaiyang
priority: normal
severity: normal
status: open
title: Some audit events are undocumented
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jul  2 02:28:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 06:28:58 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593671338.29.0.100437687393.issue41043@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +20426
pull_request: https://github.com/python/cpython/pull/21277

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

From report at bugs.python.org  Thu Jul  2 02:38:46 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 06:38:46 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593671926.35.0.627570551856.issue41165@roundup.psfhosted.org>


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


----------
title: [Python 3.10] Remove APIs deprecated since Python 3.3 -> [Python 3.10] Remove APIs deprecated long enough

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

From report at bugs.python.org  Thu Jul  2 02:45:14 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 02 Jul 2020 06:45:14 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593672314.01.0.44055282811.issue39960@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
versions:  -Python 3.7

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

From report at bugs.python.org  Thu Jul  2 02:51:40 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Thu, 02 Jul 2020 06:51:40 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593672700.79.0.818258486513.issue41192@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

Update: `os.walk`, `os.fwalk`, `pathlib.Path.glob` and `pathlib.Path.rglob` are added and documented in 3.9.

----------

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

From report at bugs.python.org  Thu Jul  2 03:05:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 07:05:23 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593673523.88.0.486152359896.issue41043@roundup.psfhosted.org>


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


New changeset ecfecc2d6ce88ae71c783f0465a508c6a1b2f2b6 by Serhiy Storchaka in branch '3.9':
[3.9] bpo-41043: Escape literal part of the path for glob(). (GH-20994). (GH-21275)
https://github.com/python/cpython/commit/ecfecc2d6ce88ae71c783f0465a508c6a1b2f2b6


----------

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

From report at bugs.python.org  Thu Jul  2 03:05:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 07:05:38 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593673538.83.0.0220820169602.issue41043@roundup.psfhosted.org>


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


New changeset e73896241e55f452656fd8070eb79f344091bca0 by Serhiy Storchaka in branch '3.8':
[3.8] bpo-41043: Escape literal part of the path for glob(). (GH-20994). (GH-21277)
https://github.com/python/cpython/commit/e73896241e55f452656fd8070eb79f344091bca0


----------

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

From report at bugs.python.org  Thu Jul  2 03:06:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 07:06:05 +0000
Subject: [issue41043] Escape the literal part of the path for glob()
In-Reply-To: <1592601403.75.0.126611663451.issue41043@roundup.psfhosted.org>
Message-ID: <1593673565.6.0.596912990333.issue41043@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul  2 03:07:19 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:07:19 +0000
Subject: [issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593673639.48.0.659949228535.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset d565be84993a3d618add139cf21038e12c60a13e by Christian Heimes in branch '3.5':
bpo-41183: Update test certs and keys (#21258)
https://github.com/python/cpython/commit/d565be84993a3d618add139cf21038e12c60a13e


----------

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

From report at bugs.python.org  Thu Jul  2 03:07:19 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:07:19 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1593673639.55.0.777052300298.issue34542@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset d565be84993a3d618add139cf21038e12c60a13e by Christian Heimes in branch '3.5':
bpo-41183: Update test certs and keys (#21258)
https://github.com/python/cpython/commit/d565be84993a3d618add139cf21038e12c60a13e


----------
nosy: +larry

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

From report at bugs.python.org  Thu Jul  2 03:09:19 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:09:19 +0000
Subject: [issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593673759.22.0.187950002219.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Thanks for the backport!

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

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

From report at bugs.python.org  Thu Jul  2 03:10:32 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:10:32 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1593673832.61.0.631741322525.issue34542@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I also needed a backport of this to 3.5.  See #41183.

Also, it looks like this issue should have been closed long ago, so I'll go ahead and do that.

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

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

From report at bugs.python.org  Thu Jul  2 03:20:40 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 02 Jul 2020 07:20:40 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593674440.09.0.747120917624.issue41165@roundup.psfhosted.org>


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

I'm all in favor to remove deprecated things, but please set a tangible deadline first. A lot of these functions have been deprecated for like a decade. Users tend to forget about deprecations or assume that removal was never going to happen. For example the removal of xml.etree.cElementTree broke a bunch of stuff although it had been deprecated since 3.0.

At a bare minimum you should list removed features in the 3.9 changelog and porting guide as "will be removed in 3.10". I would even argue to add deprecation warnings to the code in 3.9 (with permission from the RM). If the RM is against deprecation warnings, then it might be good idea to postpone removal to 3.11.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Thu Jul  2 03:27:53 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:27:53 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593674873.22.0.567265576618.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Christian:  Help!  Again!

I merged your PR, pulled a fresh copy, built it, and ran the test suite.  I get seven failures in I think the same modules.

Most of the failures are either "ssl.SSLError: [SSL] internal error (_ssl.c:728)", or some flavor of "OSError: [Errno 0] Error".  Sadly not helpful.

But!  Occasionally the test suite prints a very telling error:

ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:3233)

Attached is the output of running just those seven tests.  (One test is now working, not sure why.)

Obviously these tests pass on the buildbots, I assume that's because their OpenSSL is slightly older.  But I don't think I can ship 3.5.10rc1 if it won't build with current OpenSSL.

You should be able to simply pull the current 3.5 head (d565be84993a3d618add139cf21038e12c60a13e) to reproduce the error.

----------
title: Workaround or fix for SSL "EE_KEY_TOO_SMALL" test failures -> Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures
Added file: https://bugs.python.org/file49286/failures

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

From report at bugs.python.org  Thu Jul  2 03:28:22 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:28:22 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593674902.46.0.0722217210253.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Upgrading to release blocker.

----------
priority: high -> release blocker
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Thu Jul  2 03:40:26 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 02 Jul 2020 07:40:26 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593675626.1.0.668729338026.issue41183@roundup.psfhosted.org>


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

I'm testing with latest build of OpenSSL 1.1.1 and Fedora's DEFAULT crypto policy here. Your vendor may have configured OpenSSL with a more strict crypto policy. 

Could you please attach a full output of ./python -m test -v test_ssl?

Does the 3.6 test suite pass on your test machine?

----------

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

From report at bugs.python.org  Thu Jul  2 03:44:53 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:44:53 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593675893.55.0.938591270581.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

test_ssl was one of the seven modules that failed.  But attached here is just the output of

% ./python -m test -v test_ssl >& test_ssl_failure

----------
Added file: https://bugs.python.org/file49287/test_ssl_failure

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

From report at bugs.python.org  Thu Jul  2 03:47:50 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:47:50 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593676070.86.0.708991602064.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

The 3.6 branch of python/cpython fails as well on this machine.  Output attached.

----------
Added file: https://bugs.python.org/file49288/test_ssl_36_branch

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

From report at bugs.python.org  Thu Jul  2 03:52:58 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 07:52:58 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593676378.24.0.397250433335.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I assume this is building against the system OpenSSL.  On this machine, the "openssl", "libssl1.1", and "libssl-dev" packages are all version "1.1.1f-1ubuntu2".

The OS is "Pop!_OS" version 20.04, which is a derivative of Ubuntu 20.04.  It appears to be getting this package straight out of the Ubuntu package repo.  The maintainer is listed as "Ubuntu Developers <ubuntu-devel-discuss at lists.ubuntu.com>".

Attached is the revision history, copied and pasted out of the package manager's "changelog".

----------
Added file: https://bugs.python.org/file49289/openssl.revision.history.txt

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

From report at bugs.python.org  Thu Jul  2 04:00:04 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 08:00:04 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593676804.02.0.206642104719.issue41165@roundup.psfhosted.org>


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

I don't propose adding DeprecationWarning in 3.9 in this issue.
I don't propose removing functions that don't emit DeprecationWarning.

My first message is just a starting point. I don't propose to remove them all.

----------

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

From report at bugs.python.org  Thu Jul  2 04:02:45 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 08:02:45 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593676965.36.0.381703650673.issue41165@roundup.psfhosted.org>


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

For the record, I noticed DeprecationWarning is not shown by unittest.runner by default.

For example, https://travis-ci.org/github/necaris/python3-openid/jobs/703119609

So deprecated aliases should be not removed in 3.10.

----------

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

From report at bugs.python.org  Thu Jul  2 04:02:25 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 02 Jul 2020 08:02:25 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593676945.52.0.550908864502.issue41183@roundup.psfhosted.org>


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

test_ssl_36_branch just contains "1 test failed: test_ssl". Could you please attach a verbose run?

The problems are caused by security policy. We had similar issues in Fedora.

    - Set OPENSSL_TLS_SECURITY_LEVEL=2 as compiled-in minimum security
      level. Change meaning of SECURITY_LEVEL=2 to prohibit TLS versions
      below 1.2 and update documentation. Previous default of 1, can be set
      by calling SSL_CTX_set_security_level(), SSL_set_security_level() or
      using ':@SECLEVEL=1' CipherString value in openssl.cfg.

I can fix "SSL: DH_KEY_TOO_SMALL" in another PR. The other issues are harder to fix.

----------

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

From report at bugs.python.org  Thu Jul  2 04:04:07 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 08:04:07 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593677047.35.0.304400834309.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

./python -m test -v test_ssl >& test_ssl_verbose_36_master

----------
Added file: https://bugs.python.org/file49290/test_ssl_verbose_36_master

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

From report at bugs.python.org  Thu Jul  2 04:05:41 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 08:05:41 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593677141.91.0.648755374448.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Do you need a temporary login on one of my Pop!_OS computers, in order to test?

----------

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

From report at bugs.python.org  Thu Jul  2 04:12:28 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 02 Jul 2020 08:12:28 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593677548.03.0.480891031067.issue41183@roundup.psfhosted.org>


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


----------
pull_requests: +20427
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21278

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

From report at bugs.python.org  Thu Jul  2 04:14:14 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 02 Jul 2020 08:14:14 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593677653.99.0.0574793177652.issue41183@roundup.psfhosted.org>


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

GH-21278 takes care of test failures related to DH params.

For the other test failures somebody has to backport df6ac7e2b82d921a6e9ff5571b40c6dbcf635581 to 3.6 and 3.5. I cannot promise that I'm able to find time to do the backport today.

----------

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

From report at bugs.python.org  Thu Jul  2 04:16:20 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 08:16:20 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593677780.92.0.45892979742.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Gotcha.  Thanks for looking into it for me.  I don't think the world is super anxious about getting 3.5.10rc1 so it's not a big huge deal.  But I will wait to hear back from you.  Thanks!

----------

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

From report at bugs.python.org  Thu Jul  2 04:31:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Jul 2020 08:31:24 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593678684.25.0.634959007901.issue41165@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Jul  2 04:55:33 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jul 2020 08:55:33 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593680133.98.0.223236931015.issue41165@roundup.psfhosted.org>


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

I found most of deprecated items in my first comment are aliving by difficult reasons.

I grepped top 4000 packages and found some candidates to deprecate.


## turtle

* settiltangle is not used anywhere.
* tiltangle is also deprecated by docstring, but not in the document.
* Both methods don't emit DeprecationWarning.

TODO(easy): Update the document and emit DeprecationWarning


## email.errors

MalformedHeaderDefect is not used anywhere in top4000 packages.

But it is simple alias, and DeprecationWarning is not emit.

TODO(easy): Emit DeprecationWarning using module __getattr__.


## importlib

abc.SourceLoader.path_mtime is not used anywhere.

TODO: Remove path_mtime from the ABC and raise DeprecationWarning if path_mtime is defined in subclass in path_stats.

---

importlib should be checked by experts.  I keep TODO(easy) for new contributors.

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

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

From report at bugs.python.org  Thu Jul  2 04:56:49 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 02 Jul 2020 08:56:49 +0000
Subject: [issue18080] setting CC no longer overrides default linker for
 extension module builds on OS X
In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za>
Message-ID: <1593680209.7.0.890673715822.issue18080@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In [pypa/distutils#1](https://github.com/pypa/distutils/pull/1), I learned that the test doesn't have the intended effect. Patching `get_config_var()` has no effect because the function under test calls `get_config_vars()`. In some environments, such as PyPy3 as built on Homebrew, the first test fails.

----------
nosy: +jaraco

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

From report at bugs.python.org  Thu Jul  2 05:02:26 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Jul 2020 09:02:26 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593680546.69.0.459323400121.issue41165@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> For the record, I noticed DeprecationWarning is not shown by unittest.runner by default.

There is an open issue for this but I think it's enabled by default https://bugs.python.org/issue39892

$ cat /tmp/test_bar.py
import unittest
import warnings


class TestFoo(unittest.TestCase):

    def test_foo(self):
        self.assertEquals(1, 1)


if __name__ == "__main__":
    unittest.main()

$ python3.8 -m unittest test_bar
/private/tmp/test_bar.py:8: DeprecationWarning: Please use assertEqual instead.
  self.assertEquals(1, 1)
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

----------

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

From report at bugs.python.org  Thu Jul  2 05:03:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Jul 2020 09:03:49 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593680629.72.0.563393632691.issue41192@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +steve.dower

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

From report at bugs.python.org  Thu Jul  2 05:09:33 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 02 Jul 2020 09:09:33 +0000
Subject: [issue18080] setting CC no longer overrides default linker for
 extension module builds on OS X
In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za>
Message-ID: <1593680973.94.0.81635871334.issue18080@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

For easy reference, the relevant commit is https://github.com/python/cpython/commit/97345680dc.

----------

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

From report at bugs.python.org  Thu Jul  2 05:13:51 2020
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Thu, 02 Jul 2020 09:13:51 +0000
Subject: [issue41193] traceback when exiting on read-only file system
Message-ID: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>


New submission from Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:

[Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=1852941.]

$ touch ~/foo
touch: cannot touch '/home/fedora/foo': Read-only file system
$ python
Python 3.9.0b3 (default, Jun 10 2020, 00:00:00) 
[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib64/python3.9/site.py", line 462, in write_history
    readline.write_history_file(history)
OSError: [Errno 30] Read-only file system

Looking at /usr/lib64/python3.9/site.py, it already silently skips
PermissionError. If a user is running with the file system in ro mode,
they almost certainly are aware of the fact, since this is done either
on purpose or as a result of disk corruption, and the traceback from
python is not useful. Suppression of PermissionError was added in b2499669ef2e6dc9a2cdb49b4dc498e078167e26.

Version-Release number of selected component (if applicable):
python3-3.9.0~b3-1.fc33.x86_64

----------
messages: 372832
nosy: zbysz
priority: normal
severity: normal
status: open
title: traceback when exiting on read-only file system
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jul  2 05:14:20 2020
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Thu, 02 Jul 2020 09:14:20 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593681260.13.0.705311272677.issue41193@roundup.psfhosted.org>


Change by Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:


----------
nosy: +asottile

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

From report at bugs.python.org  Thu Jul  2 05:28:39 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 09:28:39 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
Message-ID: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>


New submission from Arcadiy Ivanov <arcadiy at ivanov.biz>:

Built with pyenv on Fedora 32. Discovered while testing PyBuilder for 3.9 compatibility.

$ abrt gdb e6ad9db
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.
Reading symbols from /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/bin/python...
warning: exec file is newer than core file.
[New LWP 450349]
warning: Unexpected size of section `.reg-xstate/450349' in core file.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/450349' in core file.
#0  0x00000000005d73d3 in init_types () at Python/Python-ast.c:1412
1412    Python/Python-ast.c: No such file or directory.
>From                To                  Syms Read   Shared Object Library
0x00007ff01d934050  0x00007ff01d948d69  Yes (*)     /lib64/libcrypt.so.2
0x00007ff01d917af0  0x00007ff01d926b95  Yes (*)     /lib64/libpthread.so.0
0x00007ff01d90b270  0x00007ff01d90c1c9  Yes (*)     /lib64/libdl.so.2
0x00007ff01d9053f0  0x00007ff01d905db0  Yes (*)     /lib64/libutil.so.1
0x00007ff01d7cd3d0  0x00007ff01d868078  Yes (*)     /lib64/libm.so.6
0x00007ff01d619670  0x00007ff01d76780f  Yes (*)     /lib64/libc.so.6
0x00007ff01d9a8110  0x00007ff01d9c8574  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007ff01d9740e0  0x00007ff01d974fcc  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_heapq.cpython-39-x86_64-linux-gnu.so
0x00007ff01d9963b0  0x00007ff01d999b2a  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/zlib.cpython-39-x86_64-linux-gnu.so
0x00007ff01d97d5f0  0x00007ff01d98abd8  Yes (*)     /lib64/libz.so.1
0x00007ff0101ed2d0  0x00007ff0101ee31c  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_bz2.cpython-39-x86_64-linux-gnu.so
0x00007ff0101a3570  0x00007ff0101af996  Yes (*)     /lib64/libbz2.so.1
0x00007ff0101e3480  0x00007ff0101e5dd6  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_lzma.cpython-39-x86_64-linux-gnu.so
0x00007ff0101b99f0  0x00007ff0101d1076  Yes (*)     /lib64/liblzma.so.5
0x00007ff01019d270  0x00007ff01019dc02  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/grp.cpython-39-x86_64-linux-gnu.so
0x00007ff01018c5e0  0x00007ff0101947f5  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/math.cpython-39-x86_64-linux-gnu.so
0x00007ff010185130  0x00007ff010185e31  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_bisect.cpython-39-x86_64-linux-gnu.so
0x00007ff01017d170  0x00007ff010180ae1  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_sha512.cpython-39-x86_64-linux-gnu.so
0x00007ff0101772c0  0x00007ff0101781dd  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_random.cpython-39-x86_64-linux-gnu.so
0x00007ff01009c570  0x00007ff0100aa101  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_datetime.cpython-39-x86_64-linux-gnu.so
0x00007ff01004d3f0  0x00007ff0100528dc  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_json.cpython-39-x86_64-linux-gnu.so
0x00007ff0100463d0  0x00007ff010047953  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_posixsubprocess.cpython-39-x86_64-linux-gnu.so
0x00007ff01003d3f0  0x00007ff01003fa46  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/select.cpython-39-x86_64-linux-gnu.so
0x00007ff00fff0510  0x00007ff00fff4e4e  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_struct.cpython-39-x86_64-linux-gnu.so
0x00007ff00ffd48c0  0x00007ff00ffe336f  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_pickle.cpython-39-x86_64-linux-gnu.so
0x00007ff00ffb97a0  0x00007ff00ffc36be  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_socket.cpython-39-x86_64-linux-gnu.so
0x00007ff00ff69540  0x00007ff00ff6ec2c  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/array.cpython-39-x86_64-linux-gnu.so
0x00007ff00ff220d0  0x00007ff00ff22431  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_opcode.cpython-39-x86_64-linux-gnu.so
0x00007ff00fdc8260  0x00007ff00fdcb03c  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/binascii.cpython-39-x86_64-linux-gnu.so
0x00007ff00fd8d4d0  0x00007ff00fdb3925  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/pyexpat.cpython-39-x86_64-linux-gnu.so
0x00007ff00fa3b680  0x00007ff00fa401f1  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_hashlib.cpython-39-x86_64-linux-gnu.so
0x00007ff00f9898d0  0x00007ff00f9d616a  Yes (*)     /lib64/libssl.so.1.1
0x00007ff00f6f8000  0x00007ff00f8a26c0  Yes (*)     /lib64/libcrypto.so.1.1
0x00007ff00fa2d260  0x00007ff00fa32cdf  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_blake2.cpython-39-x86_64-linux-gnu.so
0x00007ff00f61d260  0x00007ff00f6272da  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_ssl.cpython-39-x86_64-linux-gnu.so
0x00007ff00fa10a70  0x00007ff00fa1f92d  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-linux-gnu.so
0x00007ff00f4cd2c0  0x00007ff00f4d1d4c  Yes (*)     /lib64/libffi.so.6
0x00007ff0102b8290  0x00007ff0102b8dce  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_multiprocessing.cpython-39-x86_64-linux-gnu.so
(*): Shared library is missing debugging information.
#0  0x00000000005d73d3 in init_types () at Python/Python-ast.c:1412
#1  0x00000000005eb519 in PyAST_Check (obj=0x1e6eea0) at Python/Python-ast.c:10460
#2  0x00000000005fd618 in builtin_compile_impl (module=<optimized out>, feature_version=<optimized out>, optimize=-1, dont_inherit=0, flags=0, mode=<optimized out>, filename=0x7ff00f2a0c30, source=0x1e6eea0) at Python/bltinmodule.c:784
#3  builtin_compile (module=<optimized out>, args=<optimized out>, nargs=<optimized out>, kwnames=<optimized out>) at Python/clinic/bltinmodule.c.h:274
#4  0x00000000005c9eaa in cfunction_vectorcall_FASTCALL_KEYWORDS (func=0x7ff01058cc20, args=0x19e47e0, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/methodobject.c:440
#5  0x00000000004240f0 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775811, args=0x19e47e0, callable=0x7ff01058cc20, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#6  PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775811, args=0x19e47e0, callable=0x7ff01058cc20) at ./Include/cpython/abstract.h:127
#7  call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#8  _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3490
#9  0x000000000041d86b in _PyEval_EvalFrame (throwflag=0, f=0x19e4640, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#10 function_code_fastcall (tstate=0x18b85a0, co=<optimized out>, args=<optimized out>, nargs=2, globals=<optimized out>) at Objects/call.c:329
#11 0x00000000004240f0 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775810, args=0x19f60c0, callable=0x7ff01023c940, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#12 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775810, args=0x19f60c0, callable=0x7ff01023c940) at ./Include/cpython/abstract.h:127
#13 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#14 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3490
#15 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x19f5ef0, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#16 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=1, kwnames=0x7ff0104cb3b8, kwargs=0x19e57f0, kwcount=1, kwstep=1, defs=0x7ff010306298, defcount=2, kwdefs=0x0, 
    closure=0x0, name=0x7ff0103407f0, qualname=0x7ff0103407f0) at Python/ceval.c:4299
#17 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#18 0x0000000000424185 in _PyObject_VectorcallTstate (kwnames=0x7ff0104cb3a0, nargsf=9223372036854775809, args=0x19e57e8, callable=0x7ff01023c9d0, tstate=<optimized out>) at ./Include/cpython/abstract.h:118
#19 PyObject_Vectorcall (kwnames=0x7ff0104cb3a0, nargsf=9223372036854775809, args=0x19e57e8, callable=0x7ff01023c9d0) at ./Include/cpython/abstract.h:127
#20 call_function (kwnames=0x7ff0104cb3a0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#21 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3507
#22 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x19e5640, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#23 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=4, kwnames=0x0, kwargs=0x19f4748, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7ff0104be170, qualname=0x7ff0102fc750) at Python/ceval.c:4299
#24 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#25 0x00000000004243fe in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775812, args=0x19f4728, callable=0x7ff0102290d0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#26 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775812, args=0x19f4728, callable=0x7ff0102290d0) at ./Include/cpython/abstract.h:127
#27 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#28 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3476
#29 0x000000000041d86b in _PyEval_EvalFrame (throwflag=0, f=0x19f45b0, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#30 function_code_fastcall (tstate=0x18b85a0, co=<optimized out>, args=<optimized out>, nargs=1, globals=<optimized out>) at Objects/call.c:329
#31 0x00000000005b630c in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=1, args=0x19f4508, callable=0x7ff0103239d0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#32 method_vectorcall (method=<optimized out>, args=0x19f4510, nargsf=<optimized out>, kwnames=0x0) at Objects/classobject.c:53
#33 0x00000000004240f0 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775808, args=0x19f4510, callable=0x7ff00f414c40, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#34 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775808, args=0x19f4510, callable=0x7ff00f414c40) at ./Include/cpython/abstract.h:127
#35 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#36 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3490
#37 0x000000000041d86b in _PyEval_EvalFrame (throwflag=0, f=0x19f4390, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#38 function_code_fastcall (tstate=0x18b85a0, co=<optimized out>, args=<optimized out>, nargs=2, globals=<optimized out>) at Objects/call.c:329
#39 0x00000000004243fe in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775810, args=0x1f86ff0, callable=0x7ff0103a81f0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#40 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775810, args=0x1f86ff0, callable=0x7ff0103a81f0) at ./Include/cpython/abstract.h:127
#41 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#42 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3476
#43 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x1f86e10, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#44 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x7fff023b8630, kwcount=0, kwstep=1, defs=0x7ff0103e5148, defcount=1, kwdefs=0x0, 
    closure=0x0, name=0x7ff010580ab0, qualname=0x7ff0103db870) at Python/ceval.c:4299
#45 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#46 0x00000000005b6274 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=2, args=0x7fff023b8620, callable=0x7ff0103a83a0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#47 method_vectorcall (method=<optimized out>, args=<optimized out>, nargsf=<optimized out>, kwnames=0x0) at Objects/classobject.c:83
#48 0x0000000000422a8e in do_call_core (kwdict=0x7ff00f2d5e00, callargs=0x7ff00ece3b20, func=0x7ff00f33dd40, tstate=<optimized out>) at Python/ceval.c:5092
#49 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3552
#50 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x1cb1040, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#51 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x7fff023b8970, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7ff0105bc1f0, qualname=0x7ff0103daa80) at Python/ceval.c:4299
#52 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#53 0x0000000000434233 in _PyObject_FastCallDictTstate (tstate=0x18b85a0, callable=0x7ff0103a8550, args=0x7fff023b8960, nargsf=2, kwargs=0x0) at Objects/call.c:118
#54 0x00000000004353ed in _PyObject_Call_Prepend (tstate=tstate at entry=0x18b85a0, callable=callable at entry=0x7ff0103a8550, obj=obj at entry=0x7ff01014bc10, args=args at entry=0x7ff010202b50, kwargs=kwargs at entry=0x0) at Objects/call.c:488
#55 0x00000000004887e1 in slot_tp_call (self=self at entry=0x7ff01014bc10, args=args at entry=0x7ff010202b50, kwds=kwds at entry=0x0) at Objects/typeobject.c:6663
#56 0x0000000000434065 in _PyObject_MakeTpCall (tstate=0x18b85a0, callable=0x7ff01014bc10, args=<optimized out>, nargs=<optimized out>, keywords=0x0) at Objects/call.c:191
#57 0x0000000000424ef1 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x7ff0101531e8, callable=0x7ff01014bc10, tstate=0x18b85a0) at ./Include/cpython/abstract.h:116
#58 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x7ff0101531e8, callable=0x7ff01014bc10, tstate=0x18b85a0) at ./Include/cpython/abstract.h:103
#59 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775809, args=0x7ff0101531e8, callable=0x7ff01014bc10) at ./Include/cpython/abstract.h:127
#60 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#61 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3490
#62 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x7ff010153040, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#63 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x7fff023b8cf0, kwcount=0, kwstep=1, defs=0x7ff0103a59b8, defcount=1, kwdefs=0x0, 
    closure=0x0, name=0x7ff010580ab0, qualname=0x7ff0103a7670) at Python/ceval.c:4299
#64 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#65 0x00000000005b6274 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=2, args=0x7fff023b8ce0, callable=0x7ff0103ad430, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#66 method_vectorcall (method=<optimized out>, args=<optimized out>, nargsf=<optimized out>, kwnames=0x0) at Objects/classobject.c:83
#67 0x0000000000422a8e in do_call_core (kwdict=0x7ff01014e1c0, callargs=0x7ff010202250, func=0x7ff01014e680, tstate=<optimized out>) at Python/ceval.c:5092
#68 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3552
#69 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x7ff01021d200, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#70 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x7fff023b9030, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7ff0105bc1f0, qualname=0x7ff0103ab080) at Python/ceval.c:4299
#71 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#72 0x0000000000434233 in _PyObject_FastCallDictTstate (tstate=0x18b85a0, callable=0x7ff0103ad310, args=0x7fff023b9020, nargsf=2, kwargs=0x0) at Objects/call.c:118
#73 0x00000000004353ed in _PyObject_Call_Prepend (tstate=tstate at entry=0x18b85a0, callable=callable at entry=0x7ff0103ad310, obj=obj at entry=0x7ff01014bb50, args=args at entry=0x7ff0102191c0, kwargs=kwargs at entry=0x0) at Objects/call.c:488
#74 0x00000000004887e1 in slot_tp_call (self=self at entry=0x7ff01014bb50, args=args at entry=0x7ff0102191c0, kwds=kwds at entry=0x0) at Objects/typeobject.c:6663
#75 0x0000000000434065 in _PyObject_MakeTpCall (tstate=0x18b85a0, callable=0x7ff01014bb50, args=<optimized out>, nargs=<optimized out>, keywords=0x0) at Objects/call.c:191
#76 0x0000000000424ef1 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x7ff01014ff08, callable=0x7ff01014bb50, tstate=0x18b85a0) at ./Include/cpython/abstract.h:116
#77 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x7ff01014ff08, callable=0x7ff01014bb50, tstate=0x18b85a0) at ./Include/cpython/abstract.h:103
#78 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775809, args=0x7ff01014ff08, callable=0x7ff01014bb50) at ./Include/cpython/abstract.h:127
#79 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#80 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3490
#81 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x7ff01014fd60, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#82 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x7fff023b93b0, kwcount=0, kwstep=1, defs=0x7ff0103a59b8, defcount=1, kwdefs=0x0, 
    closure=0x0, name=0x7ff010580ab0, qualname=0x7ff0103a7670) at Python/ceval.c:4299
#83 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#84 0x00000000005b6274 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=2, args=0x7fff023b93a0, callable=0x7ff0103ad430, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#85 method_vectorcall (method=<optimized out>, args=<optimized out>, nargsf=<optimized out>, kwnames=0x0) at Objects/classobject.c:83
#86 0x0000000000422a8e in do_call_core (kwdict=0x7ff01014e3c0, callargs=0x7ff010219460, func=0x7ff01014e5c0, tstate=<optimized out>) at Python/ceval.c:5092
#87 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3552
#88 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x7ff01021d040, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#89 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x7fff023b96f0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7ff0105bc1f0, qualname=0x7ff0103ab080) at Python/ceval.c:4299
#90 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#91 0x0000000000434233 in _PyObject_FastCallDictTstate (tstate=0x18b85a0, callable=0x7ff0103ad310, args=0x7fff023b96e0, nargsf=2, kwargs=0x0) at Objects/call.c:118
#92 0x00000000004353ed in _PyObject_Call_Prepend (tstate=tstate at entry=0x18b85a0, callable=callable at entry=0x7ff0103ad310, obj=obj at entry=0x7ff01048edf0, args=args at entry=0x7ff010202b80, kwargs=kwargs at entry=0x0) at Objects/call.c:488
#93 0x00000000004887e1 in slot_tp_call (self=self at entry=0x7ff01048edf0, args=args at entry=0x7ff010202b80, kwds=kwds at entry=0x0) at Objects/typeobject.c:6663
#94 0x0000000000434065 in _PyObject_MakeTpCall (tstate=0x18b85a0, callable=0x7ff01048edf0, args=<optimized out>, nargs=<optimized out>, keywords=0x0) at Objects/call.c:191
#95 0x0000000000424ef1 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x19f07e8, callable=0x7ff01048edf0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:116
#96 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x19f07e8, callable=0x7ff01048edf0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:103
#97 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775809, args=0x19f07e8, callable=0x7ff01048edf0) at ./Include/cpython/abstract.h:127
#98 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#99 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3490
#100 0x000000000041d86b in _PyEval_EvalFrame (throwflag=0, f=0x19f05f0, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#101 function_code_fastcall (tstate=0x18b85a0, co=<optimized out>, args=<optimized out>, nargs=2, globals=<optimized out>) at Objects/call.c:329
#102 0x00000000004243fe in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775810, args=0x7ff01014f940, callable=0x7ff0103231f0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#103 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775810, args=0x7ff01014f940, callable=0x7ff0103231f0) at ./Include/cpython/abstract.h:127
#104 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#105 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3476
#106 0x000000000041d86b in _PyEval_EvalFrame (throwflag=0, f=0x7ff01014f7c0, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#107 function_code_fastcall (tstate=0x18b85a0, co=<optimized out>, args=<optimized out>, nargs=1, globals=<optimized out>) at Objects/call.c:329
#108 0x00000000004243fe in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x19e32f0, callable=0x7ff0103238b0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:118
#109 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775809, args=0x19e32f0, callable=0x7ff0103238b0) at ./Include/cpython/abstract.h:127
#110 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#111 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3476
#112 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x19e3110, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#113 _PyEval_EvalCode (tstate=tstate at entry=0x18b85a0, _co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, argcount=1, kwnames=0x0, kwargs=0x7fff023b9d78, kwcount=0, kwstep=1, defs=0x7ff010324058, defcount=11, 
    kwdefs=0x7ff0103bbb80, closure=0x0, name=0x7ff0105bc530, qualname=0x7ff0103b5440) at Python/ceval.c:4299
#114 0x0000000000434fd6 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:395
#115 0x0000000000434233 in _PyObject_FastCallDictTstate (tstate=0x18b85a0, callable=0x7ff010323310, args=0x7fff023b9d70, nargsf=1, kwargs=0x0) at Objects/call.c:118
#116 0x00000000004353ed in _PyObject_Call_Prepend (tstate=tstate at entry=0x18b85a0, callable=callable at entry=0x7ff010323310, obj=obj at entry=0x7ff01048ee20, args=args at entry=0x7ff0105c0040, kwargs=kwargs at entry=0x0) at Objects/call.c:488
#117 0x000000000048d86d in slot_tp_init (self=0x7ff01048ee20, args=0x7ff0105c0040, kwds=0x0) at Objects/typeobject.c:6903
#118 0x0000000000482907 in type_call (type=<optimized out>, type at entry=0x19a2dd0, args=args at entry=0x7ff0105c0040, kwds=kwds at entry=0x0) at Objects/typeobject.c:1023
#119 0x0000000000434065 in _PyObject_MakeTpCall (tstate=0x18b85a0, callable=0x19a2dd0, args=<optimized out>, nargs=<optimized out>, keywords=0x0) at Objects/call.c:191
#120 0x0000000000426ad0 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775808, args=0x1914d68, callable=0x19a2dd0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:116
#121 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775808, args=0x1914d68, callable=0x19a2dd0, tstate=0x18b85a0) at ./Include/cpython/abstract.h:103
#122 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775808, args=0x1914d68, callable=0x19a2dd0) at ./Include/cpython/abstract.h:127
#123 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5044
#124 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3459
#125 0x00000000004dda68 in _PyEval_EvalFrame (throwflag=0, f=0x1914bf0, tstate=0x18b85a0) at ./Include/internal/pycore_ceval.h:40
#126 _PyEval_EvalCode (tstate=0x18b85a0, _co=_co at entry=0x7ff010495240, globals=globals at entry=0x7ff01052d8c0, locals=locals at entry=0x7ff01052d8c0, args=args at entry=0x0, argcount=argcount at entry=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, 
    kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
#127 0x00000000004ddd76 in _PyEval_EvalCodeWithName (qualname=0x0, name=0x0, closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwstep=2, kwcount=0, kwargs=0x0, kwnames=0x0, argcount=0, args=0x0, locals=0x7ff01052d8c0, globals=0x7ff01052d8c0, _co=0x7ff010495240)
    at Python/ceval.c:4331
#128 PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=0x7ff01052d8c0, globals=0x7ff01052d8c0, _co=0x7ff010495240) at Python/ceval.c:4347
#129 PyEval_EvalCode (co=co at entry=0x7ff010495240, globals=globals at entry=0x7ff01052d8c0, locals=locals at entry=0x7ff01052d8c0) at Python/ceval.c:809
#130 0x000000000051ad31 in run_eval_code_obj (locals=0x7ff01052d8c0, globals=0x7ff01052d8c0, co=0x7ff010495240, tstate=0x18b85a0) at Python/pythonrun.c:1178
#131 run_mod (mod=mod at entry=0x192ecf8, filename=filename at entry=0x7ff0104d8cb0, globals=globals at entry=0x7ff01052d8c0, locals=locals at entry=0x7ff01052d8c0, flags=flags at entry=0x7fff023ba1d8, arena=arena at entry=0x7ff01055ef70) at Python/pythonrun.c:1199
#132 0x000000000051cb1f in PyRun_FileExFlags (fp=0x18b54f0, filename_str=<optimized out>, start=<optimized out>, globals=0x7ff01052d8c0, locals=0x7ff01052d8c0, closeit=1, flags=0x7fff023ba1d8) at Python/pythonrun.c:1116
#133 0x000000000051cc91 in PyRun_SimpleFileExFlags (fp=fp at entry=0x18b54f0, filename=<optimized out>, closeit=closeit at entry=1, flags=flags at entry=0x7fff023ba1d8) at Python/pythonrun.c:438
#134 0x000000000051d1e4 in PyRun_AnyFileExFlags (fp=fp at entry=0x18b54f0, filename=<optimized out>, closeit=closeit at entry=1, flags=flags at entry=0x7fff023ba1d8) at Python/pythonrun.c:87
#135 0x0000000000427d01 in pymain_run_file (cf=0x7fff023ba1d8, config=0x18b6590) at Modules/main.c:369
#136 pymain_run_python (exitcode=exitcode at entry=0x7fff023ba300) at Modules/main.c:553
#137 0x0000000000428288 in Py_RunMain () at Modules/main.c:632
#138 pymain_main (args=0x7fff023ba2c0) at Modules/main.c:662
#139 Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:686
#140 0x00007ff01d61b042 in __libc_start_main () from /lib64/libc.so.6
#141 0x000000000042705e in _start () at ./Include/object.h:430
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.8-2.fc32.x86_64 glibc-2.31-2.fc32.x86_64 libffi-3.1-24.fc32.x86_64 libxcrypt-4.4.16-3.fc32.x86_64 openssl-libs-1.1.1g-1.fc32.x86_64 xz-libs-5.2.5-1.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64

----------
messages: 372833
nosy: arcivanov
priority: normal
severity: normal
status: open
title: SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
versions: Python 3.9

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

From report at bugs.python.org  Thu Jul  2 05:32:58 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 09:32:58 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593682378.62.0.96464501028.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

I can't seem to be able to attach a gziped coredump (7MB)

----------

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

From report at bugs.python.org  Thu Jul  2 05:38:55 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Jul 2020 09:38:55 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593682735.32.0.297601170232.issue41194@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Thu Jul  2 05:42:40 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Jul 2020 09:42:40 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593682960.45.0.169900009794.issue41194@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

@arcivanov what kind of input do you pass to the compile function which leads this crash?

----------

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

From report at bugs.python.org  Thu Jul  2 05:46:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 09:46:32 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593683192.55.0.728214923692.issue41194@roundup.psfhosted.org>


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

Can you provide a script to reproduce the issue?

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

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

From report at bugs.python.org  Thu Jul  2 05:48:01 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 09:48:01 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593683281.85.0.172625123694.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

I'm right now rerunning the script with debug-level build of CPython and will report as soon as I have more data.
Any word on limits for attaching core dump?

----------

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

From report at bugs.python.org  Thu Jul  2 05:50:00 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 09:50:00 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593683400.27.0.378294992414.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

I can say that it is always reproduced, both in Travis environment (Ubuntu) and in Fedora.

----------

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

From report at bugs.python.org  Thu Jul  2 05:55:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 09:55:01 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593683701.24.0.207009610075.issue41193@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +vstinner
nosy_count: 2.0 -> 3.0
pull_requests: +20428
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21279

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

From report at bugs.python.org  Thu Jul  2 06:23:52 2020
From: report at bugs.python.org (Frank)
Date: Thu, 02 Jul 2020 10:23:52 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593685432.57.0.848154928262.issue41162@roundup.psfhosted.org>


Change by Frank <frankli0324 at hotmail.com>:


----------
nosy: +frankli

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

From report at bugs.python.org  Thu Jul  2 06:28:17 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Thu, 02 Jul 2020 10:28:17 +0000
Subject: [issue41195] Interface to OpenSSL's security level
Message-ID: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>


New submission from Matthew Hughes <matthewhughes934 at gmail.com>:

While investigating Python's SSL I noticed there was no interface for interacting with OpenSSL's SSL_CTX_{get,set}_security_level (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_security_level.html) so I thought I'd look into adding one (see attached patch). I'd be happy to put up a PR, but I have node idea if this feature would actually be desired.

----------
assignee: christian.heimes
components: SSL
files: add_ssl_context_security_level.patch
keywords: patch
messages: 372839
nosy: christian.heimes, mhughes
priority: normal
severity: normal
status: open
title: Interface to OpenSSL's security level
type: enhancement
Added file: https://bugs.python.org/file49291/add_ssl_context_security_level.patch

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

From report at bugs.python.org  Thu Jul  2 06:43:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 10:43:32 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593686612.15.0.794398629631.issue41193@roundup.psfhosted.org>


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


New changeset 0ab917e07ed64c6bfde6f6e791f9b28acc97b510 by Victor Stinner in branch 'master':
bpo-41193: Ignore OSError in readline write_history() (GH-21279)
https://github.com/python/cpython/commit/0ab917e07ed64c6bfde6f6e791f9b28acc97b510


----------

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

From report at bugs.python.org  Thu Jul  2 06:43:40 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 10:43:40 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593686620.05.0.689008287291.issue41193@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20429
pull_request: https://github.com/python/cpython/pull/21280

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

From report at bugs.python.org  Thu Jul  2 06:43:47 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 10:43:47 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593686627.74.0.603983056187.issue41193@roundup.psfhosted.org>


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


----------
pull_requests: +20430
pull_request: https://github.com/python/cpython/pull/21281

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

From report at bugs.python.org  Thu Jul  2 06:45:03 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 02 Jul 2020 10:45:03 +0000
Subject: [issue41195] Interface to OpenSSL's security level
In-Reply-To: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>
Message-ID: <1593686703.16.0.118171539419.issue41195@roundup.psfhosted.org>


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

I'm not sure it's a good idea to expose a setter for security level. In general the security level is a system-wide policy decision that should be controlled by administrators. Applications should not change this setting.

Python libraries tend to follow bad practices and cargo cult when it comes to TLS settings. Many years ago OpenSSL and Linux distributions had bad default settings. Nowadays OpenSSL has good defaults and distributions often set even stricter defaults.

A read-only getter for the policy sounds like a good idea, though.

----------

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

From report at bugs.python.org  Thu Jul  2 06:46:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Jul 2020 10:46:35 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593686795.72.0.311702426422.issue41194@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

If you aren't able to share some reproducer snippets, would you try a bisect? An interesting commit would be this ac46eb4ad66 to try and check if this crash happens before and after it?

----------

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

From report at bugs.python.org  Thu Jul  2 06:49:25 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 02 Jul 2020 10:49:25 +0000
Subject: [issue18080] setting CC no longer overrides default linker for
 extension module builds on OS X
In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za>
Message-ID: <1593686965.78.0.0319138130839.issue18080@roundup.psfhosted.org>


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

Jason, what action(s) are you expecting with regard to this and by whom? This issue has been long closed.

----------

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

From report at bugs.python.org  Thu Jul  2 06:56:21 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Thu, 02 Jul 2020 10:56:21 +0000
Subject: [issue41195] Interface to OpenSSL's security level
In-Reply-To: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>
Message-ID: <1593687381.37.0.421310956752.issue41195@roundup.psfhosted.org>


Matthew Hughes <matthewhughes934 at gmail.com> added the comment:

> Applications should not change this setting
> A read-only getter for the policy sounds like a good idea, though.

Thanks for the feedback, sounds reasonable to me. I'll happily work on getting a PR up for the read-only setter.

----------

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

From report at bugs.python.org  Thu Jul  2 07:02:30 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 11:02:30 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593687750.42.0.911912337733.issue41193@roundup.psfhosted.org>


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


New changeset 0b4c87ef8f88a4c4c325e964fa4919cef3997605 by Miss Islington (bot) in branch '3.9':
bpo-41193: Ignore OSError in readline write_history() (GH-21279)
https://github.com/python/cpython/commit/0b4c87ef8f88a4c4c325e964fa4919cef3997605


----------

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

From report at bugs.python.org  Thu Jul  2 07:02:30 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Jul 2020 11:02:30 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593687750.09.0.630939509468.issue41193@roundup.psfhosted.org>


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


New changeset 53d2b715d10e5c81cb9c86fd25e88ace4e41bc25 by Miss Islington (bot) in branch '3.8':
bpo-41193: Ignore OSError in readline write_history() (GH-21279)
https://github.com/python/cpython/commit/53d2b715d10e5c81cb9c86fd25e88ace4e41bc25


----------

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

From report at bugs.python.org  Thu Jul  2 07:07:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 11:07:04 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593688024.11.0.801249932166.issue41193@roundup.psfhosted.org>


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

Thanks Zbyszek for your bug report. It's now fixed in 3.8, 3.9 and master branches.

----------
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jul  2 07:57:43 2020
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Thu, 02 Jul 2020 11:57:43 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593691063.48.0.670602770702.issue41193@roundup.psfhosted.org>


Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl> added the comment:

Wow, that was quick. Thanks!

----------

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

From report at bugs.python.org  Thu Jul  2 08:10:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 12:10:45 +0000
Subject: [issue41175] Static analysis issues reported by GCC 10
In-Reply-To: <1593540409.36.0.220720333967.issue41175@roundup.psfhosted.org>
Message-ID: <1593691845.35.0.202404466565.issue41175@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jul  2 08:13:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 12:13:19 +0000
Subject: [issue41193] traceback when exiting on read-only file system
In-Reply-To: <1593681231.27.0.642911112114.issue41193@roundup.psfhosted.org>
Message-ID: <1593691999.28.0.195285226618.issue41193@roundup.psfhosted.org>


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

Well, two errors were already ignored (bpo-19891). I just made the "except" more generic. I don't think that we can do anything more useless than ignoring the error if the filesystem is read-only. I don't think that a warning would be useful.

----------

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

From report at bugs.python.org  Thu Jul  2 08:32:22 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Jul 2020 12:32:22 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1593693142.32.0.820702331851.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset f52bf62fe12d46267e958f80dbe1f4425b55cd0f by Christian Heimes in branch '3.5':
bpo-41183: Update finite DH params to 3072 bits (#21278)
https://github.com/python/cpython/commit/f52bf62fe12d46267e958f80dbe1f4425b55cd0f


----------

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

From report at bugs.python.org  Thu Jul  2 09:10:33 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Thu, 02 Jul 2020 13:10:33 +0000
Subject: [issue41195] Interface to OpenSSL's security level
In-Reply-To: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>
Message-ID: <1593695433.5.0.382868259469.issue41195@roundup.psfhosted.org>


Change by Matthew Hughes <matthewhughes934 at gmail.com>:


----------
pull_requests: +20431
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21282

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

From report at bugs.python.org  Thu Jul  2 09:19:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 13:19:06 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593695946.03.0.961948111931.issue41194@roundup.psfhosted.org>


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

Can you please provide a reproducer? Does PyBuilder use C extensions?

----------

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

From report at bugs.python.org  Thu Jul  2 09:20:41 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 13:20:41 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593696041.4.0.209793692396.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

No C extensions, working on giving you a reproducer.

----------

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

From report at bugs.python.org  Thu Jul  2 09:45:47 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 13:45:47 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593697547.06.0.893771985965.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

Once any of the integration tests run, the integration test environment is created and the test can be run directly from the command line via:

'.../pybuilder/target/venv/test/cpython-3.9.0.beta.3/bin/python' '.../pybuilder/src/integrationtest/python/smoke_clean_tests.py'

----------

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

From report at bugs.python.org  Thu Jul  2 09:43:47 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 13:43:47 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593697427.77.0.121250118371.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

How to reproduce:

1. Clone github.com/pybuilder/pybuilder
2. Checkout https://github.com/pybuilder/pybuilder/pull/724
3. Run `PYTHONWARNINGS=ignore python ./build.py -v -X`

The failure occurs in the integration test smoke test in smoke_clean_tests.py

----------

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

From report at bugs.python.org  Thu Jul  2 09:49:23 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 13:49:23 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593697763.24.0.887041997377.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

My guess is that the issue is related to the sys.modules manipulation, i.e. these parts of the integration test harness:

    def smoke_test(self, *args):
        old_argv = list(sys.argv)
        del sys.argv[:]
        sys.argv.append(self.build_py)
        sys.argv.extend(args)

        old_modules = dict(sys.modules)
        old_meta_path = list(sys.meta_path)
        old_cwd = getcwd()
        chdir(self.tmp_directory)
        try:
            return run_path(self.build_py, run_name="__main__")
        except SystemExit as e:
            self.assertEqual(e.code, 0, "Test did not exit successfully")
        finally:
            del sys.argv[:]
            sys.argv.extend(old_argv)

            sys.modules.clear()
            sys.modules.update(old_modules)

            del sys.meta_path[:]
            sys.meta_path.extend(old_meta_path)
            chdir(old_cwd)

    def smoke_test_module(self, module, *args):
        old_argv = list(sys.argv)
        del sys.argv[:]
        sys.argv.append("bogus")
        sys.argv.extend(args)

        old_modules = dict(sys.modules)
        old_meta_path = list(sys.meta_path)
        old_cwd = getcwd()
        chdir(self.tmp_directory)
        try:
            return run_module(module, run_name="__main__")
        except SystemExit as e:
            self.assertEqual(e.code, 0, "Test did not exit successfully")
        finally:
            del sys.argv[:]
            sys.argv.extend(old_argv)

            sys.modules.clear()
            sys.modules.update(old_modules)

            del sys.meta_path[:]
            sys.meta_path.extend(old_meta_path)
            chdir(old_cwd)

----------

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

From report at bugs.python.org  Thu Jul  2 09:52:56 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 13:52:56 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593697976.46.0.480289981746.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

To complete this report, this is a regression. This exact code runs perfectly in 2.7, 3.5 - 3.8.

This is the PR in Travis: https://travis-ci.org/github/pybuilder/pybuilder/builds/704312142

----------

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

From report at bugs.python.org  Thu Jul  2 10:09:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 14:09:39 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1593698979.78.0.0580529314598.issue40204@roundup.psfhosted.org>


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

Using https://github.com/sphinx-doc/sphinx/pull/7905 but without -W, I'm able to build the unmodified Python documentation with Sphinx 3!

I tried c_allow_pre_v3=1.

The PR was updated to add a second c_warn_on_allowed_pre_v3=0 option so we can keep -W.

----------

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

From report at bugs.python.org  Thu Jul  2 09:14:06 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 13:14:06 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593695646.68.0.320857335004.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

So as soon as I started using CPython 3.9.0b3 with debug, the stack trace changed and the corruption apparently occurs in the GC, probably because the assertion is triggered vs release-style build:

    Modules/gcmodule.c:114: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small
    Enable tracemalloc to get the memory block allocation traceback
    
    object address  : 0x7f8566e1b110
    object refcount : 1
    object type     : 0x85e160
    object type name: module
    object repr     : <module '_ast' (built-in)>
    
    Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
    Python runtime state: initialized
    
    Current thread 0x00007f85743c5740 (most recent call first):
      File "<frozen importlib._bootstrap_external>", line 587 in _compile_bytecode
      File "<frozen importlib._bootstrap_external>", line 918 in get_code
      File "<frozen importlib._bootstrap_external>", line 786 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/_vendor/pkg_resources/extern/__init__.py", line 43 in load_module
      File "<frozen importlib._bootstrap>", line 627 in _load_backward_compatible
      File "<frozen importlib._bootstrap>", line 664 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/_vendor/pkg_resources/_vendor/packaging/requirements.py", line 9 in <module>
      File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
      File "<frozen importlib._bootstrap_external>", line 790 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/extern/__init__.py", line 69 in load_module
      File "<frozen importlib._bootstrap>", line 627 in _load_backward_compatible
      File "<frozen importlib._bootstrap>", line 664 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/_vendor/pkg_resources/__init__.py", line 84 in <module>
      File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
      File "<frozen importlib._bootstrap_external>", line 790 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/extern/__init__.py", line 69 in load_module
      File "<frozen importlib._bootstrap>", line 627 in _load_backward_compatible
      File "<frozen importlib._bootstrap>", line 664 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/pip_common.py", line 19 in <module>
      File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
      File "<frozen importlib._bootstrap_external>", line 790 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/pluginloader.py", line 33 in <module>
      File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
      File "<frozen importlib._bootstrap_external>", line 790 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/reactor.py", line 38 in <module>
      File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
      File "<frozen importlib._bootstrap_external>", line 790 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/cli.py", line 37 in <module>
      File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
      File "<frozen importlib._bootstrap_external>", line 790 in exec_module
      File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
      File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
      File "./src/main/python/pybuilder/__init__.py", line 32 in bootstrap
      File "/tmp/IntegrationTestSupportte4n5vz_/build.py", line 31 in <module>
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/runpy.py", line 87 in _run_code
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/runpy.py", line 97 in _run_module_code
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/runpy.py", line 268 in run_path
      File "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py", line 72 in smoke_test
      File "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", line 30 in test_build_then_clean
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/case.py", line 550 in _callTestMethod
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/case.py", line 593 in run
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/case.py", line 653 in __call__
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/suite.py", line 122 in run
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/suite.py", line 84 in __call__
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/suite.py", line 122 in run
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/suite.py", line 84 in __call__
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/runner.py", line 176 in run
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/main.py", line 271 in runTests
      File "/home/arcivanov/.pyenv/versions/3.9.0b3-debug/lib/python3.9/unittest/main.py", line 101 in __init__
      File "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", line 34 in <module>

$ abrt gdb 78446a5
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.
Reading symbols from /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/bin/python...
warning: exec file is newer than core file.
[New LWP 494085]
warning: Unexpected size of section `.reg-xstate/494085' in core file.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/494085' in core file.
#0  0x00000000005961e9 in _PyObject_GC_UNTRACK_impl (filename=0x784cdc "Modules/gcmodule.c", lineno=2200, op=0x7f7505d6ffa0) at ./Include/internal/pycore_object.h:73
73          _PyGCHead_SET_NEXT(prev, next);
>From                To                  Syms Read   Shared Object Library
0x00007f75144f9050  0x00007f751450dd69  Yes (*)     /lib64/libcrypt.so.2
0x00007f75144dcaf0  0x00007f75144ebb95  Yes (*)     /lib64/libpthread.so.0
0x00007f75144d0270  0x00007f75144d11c9  Yes (*)     /lib64/libdl.so.2
0x00007f75144ca3f0  0x00007f75144cadb0  Yes (*)     /lib64/libutil.so.1
0x00007f75143923d0  0x00007f751442d078  Yes (*)     /lib64/libm.so.6
0x00007f75141de670  0x00007f751432c80f  Yes (*)     /lib64/libc.so.6
0x00007f751456d110  0x00007f751458d574  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007f7514538100  0x00007f7514539c25  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_heapq.cpython-39d-x86_64-linux-gnu.so
0x00007f751455a3e0  0x00007f751455ed09  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/zlib.cpython-39d-x86_64-linux-gnu.so
0x00007f7506cea5f0  0x00007f7506cf7bd8  Yes (*)     /lib64/libz.so.1
0x00007f7514552300  0x00007f7514553f8f  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_bz2.cpython-39d-x86_64-linux-gnu.so
0x00007f7506c96570  0x00007f7506ca2996  Yes (*)     /lib64/libbz2.so.1
0x00007f75145474b0  0x00007f751454abb3  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_lzma.cpython-39d-x86_64-linux-gnu.so
0x00007f7506c6d9f0  0x00007f7506c85076  Yes (*)     /lib64/liblzma.so.5
0x00007f7506d33290  0x00007f7506d340c0  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/grp.cpython-39d-x86_64-linux-gnu.so
0x00007f7506d225a0  0x00007f7506d29c84  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/math.cpython-39d-x86_64-linux-gnu.so
0x00007f7506d19160  0x00007f7506d1a20d  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_bisect.cpython-39d-x86_64-linux-gnu.so
0x00007f7506d0f1a0  0x00007f7506d14add  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_sha512.cpython-39d-x86_64-linux-gnu.so
0x00007f7506d092f0  0x00007f7506d0a9c0  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_random.cpython-39d-x86_64-linux-gnu.so
0x00007f7506b0e5a0  0x00007f7506b1f2c6  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_datetime.cpython-39d-x86_64-linux-gnu.so
0x00007f7506afb430  0x00007f7506b0408b  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_json.cpython-39d-x86_64-linux-gnu.so
0x00007f7506af3400  0x00007f7506af5350  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_posixsubprocess.cpython-39d-x86_64-linux-gnu.so
0x00007f7506ae8410  0x00007f7506aeb9bf  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/select.cpython-39d-x86_64-linux-gnu.so
0x00007f7506a5a540  0x00007f7506a5fede  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_struct.cpython-39d-x86_64-linux-gnu.so
0x00007f7506a378f0  0x00007f7506a4b945  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_pickle.cpython-39d-x86_64-linux-gnu.so
0x00007f75069da830  0x00007f75069e659b  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_socket.cpython-39d-x86_64-linux-gnu.so
0x00007f75069c7570  0x00007f75069cec85  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/array.cpython-39d-x86_64-linux-gnu.so
0x00007f75145400f0  0x00007f7514540554  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_opcode.cpython-39d-x86_64-linux-gnu.so
0x00007f75067e8280  0x00007f75067ecbcc  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/binascii.cpython-39d-x86_64-linux-gnu.so
0x00007f75067a8500  0x00007f75067d62be  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/pyexpat.cpython-39d-x86_64-linux-gnu.so
0x00007f75063956b0  0x00007f750639b885  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_hashlib.cpython-39d-x86_64-linux-gnu.so
0x00007f75062e38d0  0x00007f750633016a  Yes (*)     /lib64/libssl.so.1.1
0x00007f7506052000  0x00007f75061fc6c0  Yes (*)     /lib64/libcrypto.so.1.1
0x00007f750637d280  0x00007f750638ced0  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_blake2.cpython-39d-x86_64-linux-gnu.so
0x00007f7505f73290  0x00007f7505f807c3  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_ssl.cpython-39d-x86_64-linux-gnu.so
0x00007f7505dffa90  0x00007f7505e156d2  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_ctypes.cpython-39d-x86_64-linux-gnu.so
0x00007f75063722c0  0x00007f7506376d4c  Yes (*)     /lib64/libffi.so.6
0x00007f7506dfc2b0  0x00007f7506dfd189  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.3/lib/python3.9/lib-dynload/_multiprocessing.cpython-39d-x86_64-linux-gnu.so
(*): Shared library is missing debugging information.
#0  0x00000000005961e9 in _PyObject_GC_UNTRACK_impl (filename=0x784cdc "Modules/gcmodule.c", lineno=2200, op=0x7f7505d6ffa0) at ./Include/internal/pycore_object.h:73
#1  0x000000000059a0d0 in PyObject_GC_UnTrack (op_raw=0x7f7505d6ffa0) at Modules/gcmodule.c:2200
#2  0x000000000044a86f in list_dealloc (op=0x7f7505d6ffa0) at Objects/listobject.c:327
#3  0x000000000047c8e5 in _Py_Dealloc (op=0x7f7505d6ffa0) at Objects/object.c:2209
#4  0x0000000000608999 in _Py_DECREF (filename=0x7b1c34 "./Modules/_io/textio.c", lineno=1598, op=0x7f7505d6ffa0) at ./Include/object.h:430
#5  0x000000000060d0cc in _textiowrapper_writeflush (self=0x7f75070b39b0) at ./Modules/_io/textio.c:1598
#6  0x0000000000611a0d in _io_TextIOWrapper_flush_impl (self=0x7f75070b39b0) at ./Modules/_io/textio.c:3022
#7  0x00000000006132bc in _io_TextIOWrapper_flush (self=0x7f75070b39b0, _unused_ignored=0x0) at ./Modules/_io/clinic/textio.c.h:685
#8  0x0000000000644d88 in method_vectorcall_NOARGS (func=0x7f75070dcf50, args=0x7ffd8345a868, nargsf=1, kwnames=0x0) at Objects/descrobject.c:434
#9  0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75070dcf50, args=0x7ffd8345a868, nargsf=1, kwnames=0x0) at ./Include/cpython/abstract.h:118
#10 0x00000000004329b6 in PyObject_VectorcallMethod (name=0x7f75071a7a90, args=0x7ffd8345a868, nargsf=1, kwnames=0x0) at Objects/call.c:827
#11 0x000000000056334d in _PyObject_VectorcallMethodId (name=0x867420 <PyId_flush>, args=0x7ffd8345a868, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:237
#12 0x000000000056337e in _PyObject_CallMethodIdNoArgs (self=0x7f75070b39b0, name=0x867420 <PyId_flush>) at ./Include/cpython/abstract.h:243
#13 0x0000000000566268 in flush_std_files () at Python/pylifecycle.c:1216
#14 0x0000000000567e86 in fatal_error (stream=0x7f751437d420 <_IO_2_1_stderr_>, header=1, prefix=0x7291e0 <__func__.0> "_PyObject_AssertFailed", msg=0x728e03 "_PyObject_AssertFailed", status=-1) at Python/pylifecycle.c:2278
#15 0x0000000000567ef4 in _Py_FatalErrorFunc (func=0x7291e0 <__func__.0> "_PyObject_AssertFailed", msg=0x728e03 "_PyObject_AssertFailed") at Python/pylifecycle.c:2301
#16 0x000000000047c8bc in _PyObject_AssertFailed (obj=0x7f7506bfd890, expr=0x784d05 "gc_get_refs(g) > 0", msg=0x784cef "refcount is too small", file=0x784cdc "Modules/gcmodule.c", line=114, function=0x786830 <__func__.41> "gc_decref") at Objects/object.c:2198
#17 0x0000000000596443 in gc_decref (g=0x7f7506bfd880) at Modules/gcmodule.c:114
#18 0x0000000000596dcc in visit_decref (op=0x7f7506bfd890, parent=0x7f7507181910) at Modules/gcmodule.c:450
#19 0x0000000000450051 in list_traverse (o=0x7f7507181910, visit=0x596d4d <visit_decref>, arg=0x7f7507181910) at Objects/listobject.c:2612
#20 0x0000000000596e25 in subtract_refs (containers=0x13aa080) at Modules/gcmodule.c:469
#21 0x0000000000597e33 in deduce_unreachable (base=0x13aa080, unreachable=0x7ffd8345aab0) at Modules/gcmodule.c:1092
#22 0x0000000000598108 in collect (tstate=0x13abcc0, generation=2, n_collected=0x7ffd8345ab40, n_uncollectable=0x7ffd8345ab38, nofail=0) at Modules/gcmodule.c:1212
#23 0x00000000005987da in collect_with_callback (tstate=0x13abcc0, generation=2) at Modules/gcmodule.c:1387
#24 0x00000000005988e4 in collect_generations (tstate=0x13abcc0) at Modules/gcmodule.c:1442
#25 0x000000000059a237 in _PyObject_GC_Alloc (use_calloc=0, basicsize=64) at Modules/gcmodule.c:2242
#26 0x000000000059a274 in _PyObject_GC_Malloc (basicsize=64) at Modules/gcmodule.c:2252
#27 0x000000000059a336 in _PyObject_GC_NewVar (tp=0x860ee0 <PyTuple_Type>, nitems=5) at Modules/gcmodule.c:2281
#28 0x000000000048d643 in tuple_alloc (size=5) at Objects/tupleobject.c:92
#29 0x000000000048d6a6 in PyTuple_New (size=5) at Objects/tupleobject.c:110
#30 0x0000000000559830 in r_object (p=0x7ffd8345b460) at Python/marshal.c:1164
#31 0x000000000055a0b8 in r_object (p=0x7ffd8345b460) at Python/marshal.c:1349
#32 0x0000000000559891 in r_object (p=0x7ffd8345b460) at Python/marshal.c:1170
#33 0x000000000055a09a in r_object (p=0x7ffd8345b460) at Python/marshal.c:1346
#34 0x0000000000559891 in r_object (p=0x7ffd8345b460) at Python/marshal.c:1170
#35 0x000000000055a09a in r_object (p=0x7ffd8345b460) at Python/marshal.c:1346
#36 0x000000000055a4f3 in read_object (p=0x7ffd8345b460) at Python/marshal.c:1432
#37 0x000000000055ac60 in marshal_loads_impl (module=0x7f75070ddd70, bytes=0x7ffd8345b4e0) at Python/marshal.c:1738
#38 0x0000000000555c29 in marshal_loads (module=0x7f75070ddd70, arg=0x7f75059db940) at Python/clinic/marshal.c.h:158
#39 0x0000000000655173 in cfunction_vectorcall_O (func=0x7f75070ddf50, args=0x7f75070fa3e0, nargsf=9223372036854775809, kwnames=0x0) at Objects/methodobject.c:510
#40 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75070ddf50, args=0x7f75070fa3e0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#41 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75070ddf50, args=0x7f75070fa3e0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#42 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8345b768, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#43 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f75070fa240, throwflag=0) at Python/ceval.c:3459
#44 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f75070fa240, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#45 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750711c040, globals=0x7f7507161bf0, locals=0x0, args=0x13f2d78, argcount=1, kwnames=0x7f7507121668, kwargs=0x13f2d80, kwcount=3, kwstep=1, defs=0x7f7507131788, defcount=3, kwdefs=0x0, 
    closure=0x0, name=0x7f750711ae80, qualname=0x7f750711ae80) at Python/ceval.c:4299
#46 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7507135690, stack=0x13f2d78, nargsf=9223372036854775809, kwnames=0x7f7507121650) at Objects/call.c:395
#47 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135690, args=0x13f2d78, nargsf=9223372036854775809, kwnames=0x7f7507121650) at ./Include/cpython/abstract.h:118
#48 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135690, args=0x13f2d78, nargsf=9223372036854775809, kwnames=0x7f7507121650) at ./Include/cpython/abstract.h:127
#49 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8345cf68, oparg=4, kwnames=0x7f7507121650) at Python/ceval.c:5044
#50 0x000000000051966e in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x13f2b90, throwflag=0) at Python/ceval.c:3507
#51 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x13f2b90, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#52 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507122380, args=0x7f7505b2f968, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#53 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507137370, stack=0x7f7505b2f958, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#54 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507137370, args=0x7f7505b2f958, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#55 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507137370, args=0x7f7505b2f958, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#56 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8345e638, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#57 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505b2f7d0, throwflag=0) at Python/ceval.c:3476
#58 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505b2f7d0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#59 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x7f7505aa77e0, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#60 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x7f7505aa77d0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#61 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x7f7505aa77d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#62 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x7f7505aa77d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#63 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8345fce8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#64 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505aa7650, throwflag=0) at Python/ceval.c:3476
#65 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505aa7650, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#66 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x186e630, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#67 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x186e628, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#68 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x186e628, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#69 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x186e628, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#70 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83461388, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#71 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x186e470, throwflag=0) at Python/ceval.c:3490
#72 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x186e470, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#73 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x7f75063b5df8, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#74 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x7f75063b5de8, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#75 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x7f75063b5de8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#76 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x7f75063b5de8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#77 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83462a38, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#78 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f75063b5c50, throwflag=0) at Python/ceval.c:3490
#79 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f75063b5c50, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#80 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd83463ff0, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#81 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd83463fe0, nargsf=2, kwnames=0x0) at Objects/call.c:366
#82 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd83463fe0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#83 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd83464050) at Objects/call.c:791
#84 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#85 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f75059edbc0) at Python/import.c:1768
#86 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f75059edbc0, globals=0x0, locals=0x0, fromlist=0x0, level=0) at Python/import.c:1869
#87 0x000000000069fa60 in builtin___import__ (self=0x7f7507164950, args=0x7f750597a460, kwds=0x0) at Python/bltinmodule.c:280
#88 0x0000000000655295 in cfunction_call (func=0x7f7507164ad0, args=0x7f750597a460, kwargs=0x0) at Objects/methodobject.c:537
#89 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x17e9538, nargs=1, keywords=0x0) at Objects/call.c:191
#90 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x17e9538, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#91 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507164ad0, args=0x17e9538, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#92 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83464558, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#93 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17e9380, throwflag=0) at Python/ceval.c:3490
#94 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17e9380, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#95 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7505a00c70, args=0x7f75059d37b0, nargs=2, globals=0x7f7505a10770) at Objects/call.c:329
#96 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7505a14c30, stack=0x7f75059d37a0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#97 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7505a14c30, args=0x7f75059d37a0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#98 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7505a14c30, args=0x7f75059d37a0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#99 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83465c18, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#100 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f75059d3620, throwflag=0) at Python/ceval.c:3476
#101 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f75059d3620, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#102 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ad0, args=0x153ec48, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#103 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108190, stack=0x153ec40, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#104 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108190, args=0x153ec40, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#105 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108190, args=0x153ec40, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#106 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834672b8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#107 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x153eac0, throwflag=0) at Python/ceval.c:3490
#108 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x153eac0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#109 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x16ee3f0, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#110 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x16ee3e8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#111 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x16ee3e8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#112 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x16ee3e8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#113 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83468968, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#114 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x16ee230, throwflag=0) at Python/ceval.c:3490
#115 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x16ee230, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#116 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x1934048, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#117 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x1934038, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#118 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x1934038, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#119 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x1934038, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#120 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8346a018, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#121 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1933ea0, throwflag=0) at Python/ceval.c:3490
#122 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1933ea0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#123 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd8346b5d0, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#124 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd8346b5c0, nargsf=2, kwnames=0x0) at Objects/call.c:366
#125 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd8346b5c0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#126 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd8346b630) at Objects/call.c:791
#127 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#128 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f75059edac0) at Python/import.c:1768
#129 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f75059f8d00, globals=0x7f75059e27d0, locals=0x7f75059e27d0, fromlist=0x7f7505a38b30, level=3) at Python/import.c:1869
#130 0x000000000051f01c in import_name (tstate=0x13abcc0, f=0x7f7505f12c50, name=0x7f75059f8d00, fromlist=0x7f7505a38b30, level=0x7f75071bb340) at Python/ceval.c:5165
#131 0x0000000000516c6b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505f12c50, throwflag=0) at Python/ceval.c:3069
#132 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505f12c50, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#133 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f75059f25f0, globals=0x7f75059e27d0, locals=0x7f75059e27d0, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#134 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f75059f25f0, globals=0x7f75059e27d0, locals=0x7f75059e27d0, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#135 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f75059f25f0, globals=0x7f75059e27d0, locals=0x7f75059e27d0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#136 0x000000000050ba2f in PyEval_EvalCode (co=0x7f75059f25f0, globals=0x7f75059e27d0, locals=0x7f75059e27d0) at Python/ceval.c:809
#137 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f75059f25f0, globals=0x7f75059e27d0, locals=0x7f75059e27d0) at Python/bltinmodule.c:1035
#138 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x7f75059f36a8, nargs=2) at Python/clinic/bltinmodule.c.h:396
#139 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x7f75059f36a8, nargsf=2, kwnames=0x0) at Objects/methodobject.c:424
#140 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7507166170, tuple=0x7f75059f3690, kwargs=0x7f75059f4cb0) at Objects/call.c:230
#141 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7507166170, args=0x7f75059f3690, kwargs=0x7f75059f4cb0) at Objects/call.c:265
#142 0x00000000004311f2 in PyObject_Call (callable=0x7f7507166170, args=0x7f75059f3690, kwargs=0x7f75059f4cb0) at Objects/call.c:292
#143 0x000000000051eaf5 in do_call_core (tstate=0x13abcc0, func=0x7f7507166170, callargs=0x7f75059f3690, kwdict=0x7f75059f4cb0) at Python/ceval.c:5064
#144 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f75059dd220, throwflag=0) at Python/ceval.c:3552
#145 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f75059dd220, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#146 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750716d5f0, globals=0x7f7507101a10, locals=0x0, args=0x1808100, argcount=3, kwnames=0x0, kwargs=0x1808118, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507155d60, qualname=0x7f7507155d60) at Python/ceval.c:4299
#147 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f75071074b0, stack=0x1808100, nargsf=9223372036854775811, kwnames=0x0) at Objects/call.c:395
#148 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071074b0, args=0x1808100, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:118
#149 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071074b0, args=0x1808100, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:127
#150 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8346eb98, oparg=3, kwnames=0x0) at Python/ceval.c:5044
#151 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1807f70, throwflag=0) at Python/ceval.c:3459
#152 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1807f70, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#153 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x7f7505b3fbe0, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#154 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x7f7505b3fbd0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#155 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x7f7505b3fbd0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#156 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x7f7505b3fbd0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#157 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83470248, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#158 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505b3fa50, throwflag=0) at Python/ceval.c:3476
#159 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505b3fa50, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#160 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x17d2f30, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#161 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x17d2f28, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#162 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x17d2f28, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#163 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x17d2f28, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#164 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834718e8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#165 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17d2d70, throwflag=0) at Python/ceval.c:3490
#166 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17d2d70, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#167 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x1876b38, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#168 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x1876b28, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#169 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x1876b28, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#170 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x1876b28, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#171 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83472f98, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#172 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1876990, throwflag=0) at Python/ceval.c:3490
#173 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1876990, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#174 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd83474550, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#175 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd83474540, nargsf=2, kwnames=0x0) at Objects/call.c:366
#176 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd83474540, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#177 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd834745b0) at Objects/call.c:791
#178 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#179 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f75059e7550) at Python/import.c:1768
#180 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f75059e7550, globals=0x0, locals=0x0, fromlist=0x0, level=0) at Python/import.c:1869
#181 0x000000000069fa60 in builtin___import__ (self=0x7f7507164950, args=0x7f7505a133c0, kwds=0x0) at Python/bltinmodule.c:280
#182 0x0000000000655295 in cfunction_call (func=0x7f7507164ad0, args=0x7f7505a133c0, kwargs=0x0) at Objects/methodobject.c:537
#183 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x187b8d8, nargs=1, keywords=0x0) at Objects/call.c:191
#184 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x187b8d8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#185 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507164ad0, args=0x187b8d8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#186 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83474ab8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#187 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x187b720, throwflag=0) at Python/ceval.c:3490
#188 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x187b720, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#189 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7505ba5ad0, args=0x7f7505ca2f70, nargs=2, globals=0x7f7505b44cb0) at Objects/call.c:329
#190 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7505b4c9b0, stack=0x7f7505ca2f60, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#191 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7505b4c9b0, args=0x7f7505ca2f60, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#192 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7505b4c9b0, args=0x7f7505ca2f60, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#193 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83476178, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#194 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505ca2de0, throwflag=0) at Python/ceval.c:3476
#195 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505ca2de0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#196 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ad0, args=0x7f7505aa75d8, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#197 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108190, stack=0x7f7505aa75d0, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#198 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108190, args=0x7f7505aa75d0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#199 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108190, args=0x7f7505aa75d0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#200 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83477818, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#201 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505aa7450, throwflag=0) at Python/ceval.c:3490
#202 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505aa7450, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#203 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x1880bb0, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#204 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x1880ba8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#205 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x1880ba8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#206 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x1880ba8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#207 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83478ec8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#208 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x18809f0, throwflag=0) at Python/ceval.c:3490
#209 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x18809f0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#210 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x17ffd08, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#211 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x17ffcf8, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#212 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x17ffcf8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#213 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x17ffcf8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#214 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8347a578, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#215 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17ffb60, throwflag=0) at Python/ceval.c:3490
#216 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17ffb60, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#217 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd8347bb30, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#218 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd8347bb20, nargsf=2, kwnames=0x0) at Objects/call.c:366
#219 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd8347bb20, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#220 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd8347bb90) at Objects/call.c:791
#221 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#222 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f7505afd240) at Python/import.c:1768
#223 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f7505afd240, globals=0x0, locals=0x0, fromlist=0x0, level=0) at Python/import.c:1869
#224 0x000000000069fa60 in builtin___import__ (self=0x7f7507164950, args=0x7f7505abd690, kwds=0x0) at Python/bltinmodule.c:280
#225 0x0000000000655295 in cfunction_call (func=0x7f7507164ad0, args=0x7f7505abd690, kwargs=0x0) at Objects/methodobject.c:537
#226 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x17f61a0, nargs=1, keywords=0x0) at Objects/call.c:191
#227 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x17f61a0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#228 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507164ad0, args=0x17f61a0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#229 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8347c098, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#230 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17f6030, throwflag=0) at Python/ceval.c:3490
#231 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17f6030, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#232 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7505abe380, globals=0x7f7505afea70, locals=0x7f7505afea70, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#233 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f7505abe380, globals=0x7f7505afea70, locals=0x7f7505afea70, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#234 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f7505abe380, globals=0x7f7505afea70, locals=0x7f7505afea70, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#235 0x000000000050ba2f in PyEval_EvalCode (co=0x7f7505abe380, globals=0x7f7505afea70, locals=0x7f7505afea70) at Python/ceval.c:809
#236 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f7505abe380, globals=0x7f7505afea70, locals=0x7f7505afea70) at Python/bltinmodule.c:1035
#237 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x7f7505abd6f8, nargs=2) at Python/clinic/bltinmodule.c.h:396
#238 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x7f7505abd6f8, nargsf=2, kwnames=0x0) at Objects/methodobject.c:424
#239 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7507166170, tuple=0x7f7505abd6e0, kwargs=0x7f7505afe6b0) at Objects/call.c:230
#240 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7507166170, args=0x7f7505abd6e0, kwargs=0x7f7505afe6b0) at Objects/call.c:265
#241 0x00000000004311f2 in PyObject_Call (callable=0x7f7507166170, args=0x7f7505abd6e0, kwargs=0x7f7505afe6b0) at Objects/call.c:292
#242 0x000000000051eaf5 in do_call_core (tstate=0x13abcc0, func=0x7f7507166170, callargs=0x7f7505abd6e0, kwdict=0x7f7505afe6b0) at Python/ceval.c:5064
#243 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x182b590, throwflag=0) at Python/ceval.c:3552
#244 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x182b590, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#245 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750716d5f0, globals=0x7f7507101a10, locals=0x0, args=0x1842810, argcount=3, kwnames=0x0, kwargs=0x1842828, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507155d60, qualname=0x7f7507155d60) at Python/ceval.c:4299
#246 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f75071074b0, stack=0x1842810, nargsf=9223372036854775811, kwnames=0x0) at Objects/call.c:395
#247 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071074b0, args=0x1842810, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:118
#248 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071074b0, args=0x1842810, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:127
#249 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8347f2b8, oparg=3, kwnames=0x0) at Python/ceval.c:5044
#250 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1842680, throwflag=0) at Python/ceval.c:3459
#251 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1842680, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#252 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x18368a0, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#253 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x1836890, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#254 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x1836890, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#255 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x1836890, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#256 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83480968, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#257 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1836710, throwflag=0) at Python/ceval.c:3476
#258 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1836710, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#259 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x17bb8b0, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#260 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x17bb8a8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#261 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x17bb8a8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#262 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x17bb8a8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#263 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83482008, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#264 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17bb6f0, throwflag=0) at Python/ceval.c:3490
#265 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17bb6f0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#266 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x1879718, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#267 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x1879708, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#268 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x1879708, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#269 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x1879708, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#270 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834836b8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#271 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1879570, throwflag=0) at Python/ceval.c:3490
#272 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1879570, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#273 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd83484c70, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#274 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd83484c60, nargsf=2, kwnames=0x0) at Objects/call.c:366
#275 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd83484c60, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#276 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd83484cd0) at Objects/call.c:791
#277 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#278 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f7505afb3c0) at Python/import.c:1768
#279 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f7505afb3c0, globals=0x0, locals=0x0, fromlist=0x0, level=0) at Python/import.c:1869
#280 0x000000000069fa60 in builtin___import__ (self=0x7f7507164950, args=0x7f7505b75f50, kwds=0x0) at Python/bltinmodule.c:280
#281 0x0000000000655295 in cfunction_call (func=0x7f7507164ad0, args=0x7f7505b75f50, kwargs=0x0) at Objects/methodobject.c:537
#282 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x1849c98, nargs=1, keywords=0x0) at Objects/call.c:191
#283 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507164ad0, args=0x1849c98, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#284 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507164ad0, args=0x1849c98, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#285 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834851d8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#286 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1849ae0, throwflag=0) at Python/ceval.c:3490
#287 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1849ae0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#288 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7505ba5ad0, args=0x7f75066741e0, nargs=2, globals=0x7f7505b44cb0) at Objects/call.c:329
#289 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7505b4c9b0, stack=0x7f75066741d0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#290 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7505b4c9b0, args=0x7f75066741d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#291 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7505b4c9b0, args=0x7f75066741d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#292 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83486898, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#293 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506674050, throwflag=0) at Python/ceval.c:3476
#294 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506674050, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#295 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ad0, args=0x1829a48, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#296 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108190, stack=0x1829a40, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#297 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108190, args=0x1829a40, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#298 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108190, args=0x1829a40, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#299 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83487f38, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#300 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x18298c0, throwflag=0) at Python/ceval.c:3490
#301 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x18298c0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#302 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x1837e90, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#303 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x1837e88, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#304 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x1837e88, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#305 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x1837e88, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#306 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834895e8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#307 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1837cd0, throwflag=0) at Python/ceval.c:3490
#308 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1837cd0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#309 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x1854a28, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#310 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x1854a18, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#311 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x1854a18, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#312 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x1854a18, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#313 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8348ac98, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#314 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1854880, throwflag=0) at Python/ceval.c:3490
#315 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1854880, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#316 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd8348c250, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#317 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd8348c240, nargsf=2, kwnames=0x0) at Objects/call.c:366
#318 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd8348c240, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#319 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd8348c2b0) at Objects/call.c:791
#320 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#321 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f75069169a0) at Python/import.c:1768
#322 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f75069169a0, globals=0x7f7505b77ef0, locals=0x7f7505b77ef0, fromlist=0x7f7505b75e60, level=0) at Python/import.c:1869
#323 0x000000000051f01c in import_name (tstate=0x13abcc0, f=0x18567f0, name=0x7f75069169a0, fromlist=0x7f7505b75e60, level=0x7f75071bb280) at Python/ceval.c:5165
#324 0x0000000000516c6b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x18567f0, throwflag=0) at Python/ceval.c:3069
#325 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x18567f0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#326 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7505afaa00, globals=0x7f7505b77ef0, locals=0x7f7505b77ef0, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#327 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f7505afaa00, globals=0x7f7505b77ef0, locals=0x7f7505b77ef0, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#328 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f7505afaa00, globals=0x7f7505b77ef0, locals=0x7f7505b77ef0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#329 0x000000000050ba2f in PyEval_EvalCode (co=0x7f7505afaa00, globals=0x7f7505b77ef0, locals=0x7f7505b77ef0) at Python/ceval.c:809
#330 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f7505afaa00, globals=0x7f7505b77ef0, locals=0x7f7505b77ef0) at Python/bltinmodule.c:1035
#331 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x7f7505b75d38, nargs=2) at Python/clinic/bltinmodule.c.h:396
#332 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x7f7505b75d38, nargsf=2, kwnames=0x0) at Objects/methodobject.c:424
#333 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7507166170, tuple=0x7f7505b75d20, kwargs=0x7f7505b77fb0) at Objects/call.c:230
#334 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7507166170, args=0x7f7505b75d20, kwargs=0x7f7505b77fb0) at Objects/call.c:265
#335 0x00000000004311f2 in PyObject_Call (callable=0x7f7507166170, args=0x7f7505b75d20, kwargs=0x7f7505b77fb0) at Objects/call.c:292
#336 0x000000000051eaf5 in do_call_core (tstate=0x13abcc0, func=0x7f7507166170, callargs=0x7f7505b75d20, kwdict=0x7f7505b77fb0) at Python/ceval.c:5064
#337 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1844150, throwflag=0) at Python/ceval.c:3552
#338 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1844150, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#339 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750716d5f0, globals=0x7f7507101a10, locals=0x0, args=0x185fc90, argcount=3, kwnames=0x0, kwargs=0x185fca8, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507155d60, qualname=0x7f7507155d60) at Python/ceval.c:4299
#340 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f75071074b0, stack=0x185fc90, nargsf=9223372036854775811, kwnames=0x0) at Objects/call.c:395
#341 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071074b0, args=0x185fc90, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:118
#342 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071074b0, args=0x185fc90, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:127
#343 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8348f818, oparg=3, kwnames=0x0) at Python/ceval.c:5044
#344 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x185fb00, throwflag=0) at Python/ceval.c:3459
#345 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x185fb00, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#346 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x18519b0, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#347 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x18519a0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#348 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x18519a0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#349 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x18519a0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#350 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83490ec8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#351 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1851820, throwflag=0) at Python/ceval.c:3476
#352 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1851820, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#353 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x18799a0, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#354 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x1879998, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#355 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x1879998, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#356 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x1879998, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#357 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83492568, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#358 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x18797e0, throwflag=0) at Python/ceval.c:3490
#359 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x18797e0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#360 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x1879bf8, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#361 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x1879be8, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#362 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x1879be8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#363 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x1879be8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#364 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83493c18, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#365 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1879a50, throwflag=0) at Python/ceval.c:3490
#366 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1879a50, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#367 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd834951d0, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#368 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd834951c0, nargsf=2, kwnames=0x0) at Objects/call.c:366
#369 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd834951c0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#370 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd83495230) at Objects/call.c:791
#371 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#372 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f75068cfd60) at Python/import.c:1768
#373 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f75068cfd60, globals=0x7f7505b6ad70, locals=0x7f7505b6ad70, fromlist=0x7f7505b69d20, level=0) at Python/import.c:1869
#374 0x000000000051f01c in import_name (tstate=0x13abcc0, f=0x1879cb0, name=0x7f75068cfd60, fromlist=0x7f7505b69d20, level=0x7f75071bb280) at Python/ceval.c:5165
#375 0x0000000000516c6b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1879cb0, throwflag=0) at Python/ceval.c:3069
#376 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1879cb0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#377 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7505afa860, globals=0x7f7505b6ad70, locals=0x7f7505b6ad70, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#378 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f7505afa860, globals=0x7f7505b6ad70, locals=0x7f7505b6ad70, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#379 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f7505afa860, globals=0x7f7505b6ad70, locals=0x7f7505b6ad70, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#380 0x000000000050ba2f in PyEval_EvalCode (co=0x7f7505afa860, globals=0x7f7505b6ad70, locals=0x7f7505b6ad70) at Python/ceval.c:809
#381 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f7505afa860, globals=0x7f7505b6ad70, locals=0x7f7505b6ad70) at Python/bltinmodule.c:1035
#382 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x7f7505b75c48, nargs=2) at Python/clinic/bltinmodule.c.h:396
#383 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x7f7505b75c48, nargsf=2, kwnames=0x0) at Objects/methodobject.c:424
#384 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7507166170, tuple=0x7f7505b75c30, kwargs=0x7f7505b771d0) at Objects/call.c:230
#385 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7507166170, args=0x7f7505b75c30, kwargs=0x7f7505b771d0) at Objects/call.c:265
#386 0x00000000004311f2 in PyObject_Call (callable=0x7f7507166170, args=0x7f7505b75c30, kwargs=0x7f7505b771d0) at Objects/call.c:292
#387 0x000000000051eaf5 in do_call_core (tstate=0x13abcc0, func=0x7f7507166170, callargs=0x7f7505b75c30, kwdict=0x7f7505b771d0) at Python/ceval.c:5064
#388 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1795410, throwflag=0) at Python/ceval.c:3552
#389 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1795410, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#390 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750716d5f0, globals=0x7f7507101a10, locals=0x0, args=0x16791a0, argcount=3, kwnames=0x0, kwargs=0x16791b8, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507155d60, qualname=0x7f7507155d60) at Python/ceval.c:4299
#391 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f75071074b0, stack=0x16791a0, nargsf=9223372036854775811, kwnames=0x0) at Objects/call.c:395
#392 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071074b0, args=0x16791a0, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:118
#393 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071074b0, args=0x16791a0, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:127
#394 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83498798, oparg=3, kwnames=0x0) at Python/ceval.c:5044
#395 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1679010, throwflag=0) at Python/ceval.c:3459
#396 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1679010, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#397 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x17df8f0, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#398 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x17df8e0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#399 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x17df8e0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#400 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x17df8e0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#401 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd83499e48, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#402 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17df760, throwflag=0) at Python/ceval.c:3476
#403 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17df760, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#404 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x1779f00, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#405 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x1779ef8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#406 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x1779ef8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#407 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x1779ef8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#408 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8349b4e8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#409 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1779d40, throwflag=0) at Python/ceval.c:3490
#410 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1779d40, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#411 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x187f2c8, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#412 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x187f2b8, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#413 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x187f2b8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#414 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x187f2b8, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#415 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd8349cb98, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#416 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x187f120, throwflag=0) at Python/ceval.c:3490
#417 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x187f120, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#418 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd8349e150, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#419 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd8349e140, nargsf=2, kwnames=0x0) at Objects/call.c:366
#420 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd8349e140, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#421 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd8349e1b0) at Objects/call.c:791
#422 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#423 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f7506942fa0) at Python/import.c:1768
#424 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f7506942fa0, globals=0x7f7505ba3f50, locals=0x7f7505ba3f50, fromlist=0x7f7505b505f0, level=0) at Python/import.c:1869
#425 0x000000000051f01c in import_name (tstate=0x13abcc0, f=0x7f7505d28650, name=0x7f7506942fa0, fromlist=0x7f7505b505f0, level=0x7f75071bb280) at Python/ceval.c:5165
#426 0x0000000000516c6b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505d28650, throwflag=0) at Python/ceval.c:3069
#427 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505d28650, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#428 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7505b6f110, globals=0x7f7505ba3f50, locals=0x7f7505ba3f50, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#429 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f7505b6f110, globals=0x7f7505ba3f50, locals=0x7f7505ba3f50, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#430 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f7505b6f110, globals=0x7f7505ba3f50, locals=0x7f7505ba3f50, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#431 0x000000000050ba2f in PyEval_EvalCode (co=0x7f7505b6f110, globals=0x7f7505ba3f50, locals=0x7f7505ba3f50) at Python/ceval.c:809
#432 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f7505b6f110, globals=0x7f7505ba3f50, locals=0x7f7505ba3f50) at Python/bltinmodule.c:1035
#433 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x7f7505b69bf8, nargs=2) at Python/clinic/bltinmodule.c.h:396
#434 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x7f7505b69bf8, nargsf=2, kwnames=0x0) at Objects/methodobject.c:424
#435 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7507166170, tuple=0x7f7505b69be0, kwargs=0x7f7505b65050) at Objects/call.c:230
#436 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7507166170, args=0x7f7505b69be0, kwargs=0x7f7505b65050) at Objects/call.c:265
#437 0x00000000004311f2 in PyObject_Call (callable=0x7f7507166170, args=0x7f7505b69be0, kwargs=0x7f7505b65050) at Objects/call.c:292
#438 0x000000000051eaf5 in do_call_core (tstate=0x13abcc0, func=0x7f7507166170, callargs=0x7f7505b69be0, kwdict=0x7f7505b65050) at Python/ceval.c:5064
#439 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17ef760, throwflag=0) at Python/ceval.c:3552
#440 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17ef760, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#441 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750716d5f0, globals=0x7f7507101a10, locals=0x0, args=0x7f7505d289e0, argcount=3, kwnames=0x0, kwargs=0x7f7505d289f8, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507155d60, qualname=0x7f7507155d60) at Python/ceval.c:4299
#442 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f75071074b0, stack=0x7f7505d289e0, nargsf=9223372036854775811, kwnames=0x0) at Objects/call.c:395
#443 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071074b0, args=0x7f7505d289e0, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:118
#444 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071074b0, args=0x7f7505d289e0, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:127
#445 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834a1718, oparg=3, kwnames=0x0) at Python/ceval.c:5044
#446 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7505d28850, throwflag=0) at Python/ceval.c:3459
#447 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7505d28850, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#448 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x17ea880, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#449 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x17ea870, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#450 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x17ea870, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#451 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x17ea870, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#452 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834a2dc8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#453 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17ea6f0, throwflag=0) at Python/ceval.c:3476
#454 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17ea6f0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#455 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x186a700, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#456 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x186a6f8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#457 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x186a6f8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#458 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x186a6f8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#459 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834a4468, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#460 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x186a540, throwflag=0) at Python/ceval.c:3490
#461 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x186a540, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#462 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x185df68, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#463 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x185df58, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#464 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x185df58, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#465 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x185df58, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#466 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834a5b18, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#467 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x185ddc0, throwflag=0) at Python/ceval.c:3490
#468 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x185ddc0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#469 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd834a70d0, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#470 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd834a70c0, nargsf=2, kwnames=0x0) at Objects/call.c:366
#471 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd834a70c0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#472 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd834a7130) at Objects/call.c:791
#473 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#474 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f7506bb2940) at Python/import.c:1768
#475 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f7506bb2940, globals=0x7f7505d33ad0, locals=0x7f7505d33ad0, fromlist=0x7f7505b88eb0, level=0) at Python/import.c:1869
#476 0x000000000051f01c in import_name (tstate=0x13abcc0, f=0x1829190, name=0x7f7506bb2940, fromlist=0x7f7505b88eb0, level=0x7f75071bb280) at Python/ceval.c:5165
#477 0x0000000000516c6b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1829190, throwflag=0) at Python/ceval.c:3069
#478 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1829190, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#479 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7505b9fa00, globals=0x7f7505d33ad0, locals=0x7f7505d33ad0, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#480 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f7505b9fa00, globals=0x7f7505d33ad0, locals=0x7f7505d33ad0, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#481 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f7505b9fa00, globals=0x7f7505d33ad0, locals=0x7f7505d33ad0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#482 0x000000000050ba2f in PyEval_EvalCode (co=0x7f7505b9fa00, globals=0x7f7505d33ad0, locals=0x7f7505d33ad0) at Python/ceval.c:809
#483 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f7505b9fa00, globals=0x7f7505d33ad0, locals=0x7f7505d33ad0) at Python/bltinmodule.c:1035
#484 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x7f7505bbf3d8, nargs=2) at Python/clinic/bltinmodule.c.h:396
#485 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x7f7505bbf3d8, nargsf=2, kwnames=0x0) at Objects/methodobject.c:424
#486 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7507166170, tuple=0x7f7505bbf3c0, kwargs=0x7f7505b98dd0) at Objects/call.c:230
#487 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7507166170, args=0x7f7505bbf3c0, kwargs=0x7f7505b98dd0) at Objects/call.c:265
#488 0x00000000004311f2 in PyObject_Call (callable=0x7f7507166170, args=0x7f7505bbf3c0, kwargs=0x7f7505b98dd0) at Objects/call.c:292
#489 0x000000000051eaf5 in do_call_core (tstate=0x13abcc0, func=0x7f7507166170, callargs=0x7f7505bbf3c0, kwdict=0x7f7505b98dd0) at Python/ceval.c:5064
#490 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17f0d50, throwflag=0) at Python/ceval.c:3552
#491 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17f0d50, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#492 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750716d5f0, globals=0x7f7507101a10, locals=0x0, args=0x185c260, argcount=3, kwnames=0x0, kwargs=0x185c278, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507155d60, qualname=0x7f7507155d60) at Python/ceval.c:4299
#493 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f75071074b0, stack=0x185c260, nargsf=9223372036854775811, kwnames=0x0) at Objects/call.c:395
#494 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071074b0, args=0x185c260, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:118
#495 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071074b0, args=0x185c260, nargsf=9223372036854775811, kwnames=0x0) at ./Include/cpython/abstract.h:127
#496 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834aa698, oparg=3, kwnames=0x0) at Python/ceval.c:5044
#497 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x185c0d0, throwflag=0) at Python/ceval.c:3459
#498 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x185c0d0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#499 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750711cad0, args=0x18477e0, nargs=2, globals=0x7f7507161bf0) at Objects/call.c:329
#500 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507135e10, stack=0x18477d0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#501 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507135e10, args=0x18477d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#502 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507135e10, args=0x18477d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#503 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834abd48, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#504 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1847650, throwflag=0) at Python/ceval.c:3476
#505 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1847650, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#506 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507173ba0, args=0x17ed970, nargs=1, globals=0x7f7507101a10) at Objects/call.c:329
#507 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507108230, stack=0x17ed968, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#508 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507108230, args=0x17ed968, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#509 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507108230, args=0x17ed968, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#510 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834ad3e8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#511 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x17ed7b0, throwflag=0) at Python/ceval.c:3490
#512 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x17ed7b0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#513 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d6c0, args=0x1864a98, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#514 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f75071095f0, stack=0x1864a88, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#515 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f75071095f0, args=0x1864a88, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#516 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f75071095f0, args=0x1864a88, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#517 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834aea98, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#518 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x18648f0, throwflag=0) at Python/ceval.c:3490
#519 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x18648f0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#520 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f750717d790, args=0x7ffd834b0050, nargs=2, globals=0x7f7507101a10) at Objects/call.c:329
#521 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7507109690, stack=0x7ffd834b0040, nargsf=2, kwnames=0x0) at Objects/call.c:366
#522 0x00000000004303ef in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507109690, args=0x7ffd834b0040, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#523 0x0000000000432897 in object_vacall (tstate=0x13abcc0, base=0x0, callable=0x7f7507109690, vargs=0x7ffd834b00b0) at Objects/call.c:791
#524 0x0000000000432caf in _PyObject_CallMethodIdObjArgs (obj=0x0, name=0x8671e0 <PyId__find_and_load.7>) at Objects/call.c:882
#525 0x0000000000549fbb in import_find_and_load (tstate=0x13abcc0, abs_name=0x7f7506c21820) at Python/import.c:1768
#526 0x000000000054a3c0 in PyImport_ImportModuleLevelObject (name=0x7f7506c21820, globals=0x7f7505cc4ef0, locals=0x85e780 <_Py_NoneStruct>, fromlist=0x85e780 <_Py_NoneStruct>, level=0) at Python/import.c:1869
#527 0x000000000051f01c in import_name (tstate=0x13abcc0, f=0x176cdc0, name=0x7f7506c21820, fromlist=0x85e780 <_Py_NoneStruct>, level=0x7f75071bb280) at Python/ceval.c:5165
#528 0x0000000000516c6b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x176cdc0, throwflag=0) at Python/ceval.c:3069
#529 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x176cdc0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#530 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7505cd81e0, args=0x1858da0, nargs=0, globals=0x7f7505cc4ef0) at Objects/call.c:329
#531 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7506ab5870, stack=0x1858da0, nargsf=9223372036854775808, kwnames=0x0) at Objects/call.c:366
#532 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506ab5870, args=0x1858da0, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:118
#533 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506ab5870, args=0x1858da0, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#534 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834b1aa8, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#535 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1858c30, throwflag=0) at Python/ceval.c:3490
#536 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1858c30, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#537 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7505cd8110, globals=0x7f7506ab0710, locals=0x7f7506ab0710, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#538 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f7505cd8110, globals=0x7f7506ab0710, locals=0x7f7506ab0710, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#539 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f7505cd8110, globals=0x7f7506ab0710, locals=0x7f7506ab0710, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#540 0x000000000050ba2f in PyEval_EvalCode (co=0x7f7505cd8110, globals=0x7f7506ab0710, locals=0x7f7506ab0710) at Python/ceval.c:809
#541 0x00000000006a0a29 in builtin_exec_impl (module=0x7f7507164950, source=0x7f7505cd8110, globals=0x7f7506ab0710, locals=0x7f7506ab0710) at Python/bltinmodule.c:1035
#542 0x000000000069e868 in builtin_exec (module=0x7f7507164950, args=0x1843200, nargs=2) at Python/clinic/bltinmodule.c.h:396
#543 0x0000000000654dae in cfunction_vectorcall_FASTCALL (func=0x7f7507166170, args=0x1843200, nargsf=9223372036854775810, kwnames=0x0) at Objects/methodobject.c:424
#544 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7507166170, args=0x1843200, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#545 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7507166170, args=0x1843200, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#546 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834b3458, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#547 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1843040, throwflag=0) at Python/ceval.c:3490
#548 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1843040, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#549 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506dc9110, globals=0x7f7506eb8c50, locals=0x0, args=0x184bc78, argcount=7, kwnames=0x0, kwargs=0x184bcb0, kwcount=0, kwstep=1, defs=0x7f7506ddc7d8, defcount=5, kwdefs=0x0, closure=0x0, 
    name=0x7f7506dda8e0, qualname=0x7f7506dda8e0) at Python/ceval.c:4299
#550 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506dd8910, stack=0x184bc78, nargsf=9223372036854775815, kwnames=0x0) at Objects/call.c:395
#551 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506dd8910, args=0x184bc78, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:118
#552 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506dd8910, args=0x184bc78, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:127
#553 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834b4c78, oparg=7, kwnames=0x0) at Python/ceval.c:5044
#554 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x184bab0, throwflag=0) at Python/ceval.c:3490
#555 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x184bab0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#556 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506dc9520, globals=0x7f7506eb8c50, locals=0x0, args=0x1888060, argcount=3, kwnames=0x7f7506e7dc48, kwargs=0x1888078, kwcount=2, kwstep=1, defs=0x7f7506ddc848, defcount=5, kwdefs=0x0, 
    closure=0x0, name=0x7f7506ddaa00, qualname=0x7f7506ddaa00) at Python/ceval.c:4299
#557 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506d53230, stack=0x1888060, nargsf=9223372036854775811, kwnames=0x7f7506e7dc30) at Objects/call.c:395
#558 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506d53230, args=0x1888060, nargsf=9223372036854775811, kwnames=0x7f7506e7dc30) at ./Include/cpython/abstract.h:118
#559 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506d53230, args=0x1888060, nargsf=9223372036854775811, kwnames=0x7f7506e7dc30) at ./Include/cpython/abstract.h:127
#560 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834b6488, oparg=5, kwnames=0x7f7506e7dc30) at Python/ceval.c:5044
#561 0x000000000051966e in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1887e90, throwflag=0) at Python/ceval.c:3507
#562 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1887e90, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#563 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506dcfba0, globals=0x7f7506eb8c50, locals=0x0, args=0x1869c98, argcount=1, kwnames=0x7f750705f2e8, kwargs=0x1869ca0, kwcount=1, kwstep=1, defs=0x7f7506e7dba8, defcount=2, kwdefs=0x0, 
    closure=0x0, name=0x7f7507036e80, qualname=0x7f7507036e80) at Python/ceval.c:4299
#564 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506d535f0, stack=0x1869c98, nargsf=9223372036854775809, kwnames=0x7f750705f2d0) at Objects/call.c:395
#565 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506d535f0, args=0x1869c98, nargsf=9223372036854775809, kwnames=0x7f750705f2d0) at ./Include/cpython/abstract.h:118
#566 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506d535f0, args=0x1869c98, nargsf=9223372036854775809, kwnames=0x7f750705f2d0) at ./Include/cpython/abstract.h:127
#567 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834b7ca8, oparg=2, kwnames=0x7f750705f2d0) at Python/ceval.c:5044
#568 0x000000000051966e in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x1869af0, throwflag=0) at Python/ceval.c:3507
#569 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x1869af0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#570 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506eb5110, globals=0x7f75070b87d0, locals=0x0, args=0x1500098, argcount=4, kwnames=0x0, kwargs=0x15000b8, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f7507051280, qualname=0x7f7506eb37b0) at Python/ceval.c:4299
#571 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506c4dd70, stack=0x1500098, nargsf=9223372036854775812, kwnames=0x0) at Objects/call.c:395
#572 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506c4dd70, args=0x1500098, nargsf=9223372036854775812, kwnames=0x0) at ./Include/cpython/abstract.h:118
#573 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506c4dd70, args=0x1500098, nargsf=9223372036854775812, kwnames=0x0) at ./Include/cpython/abstract.h:127
#574 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834b94e8, oparg=4, kwnames=0x0) at Python/ceval.c:5044
#575 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x14fff20, throwflag=0) at Python/ceval.c:3476
#576 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x14fff20, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#577 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7507045d40, args=0x14cfb70, nargs=1, globals=0x7f75070b5050) at Objects/call.c:329
#578 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7506c4df50, stack=0x14cfb68, nargsf=1, kwnames=0x0) at Objects/call.c:366
#579 0x000000000063b8f8 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506c4df50, args=0x14cfb68, nargsf=1, kwnames=0x0) at ./Include/cpython/abstract.h:118
#580 0x000000000063bcbe in method_vectorcall (method=0x7f7506bfd6b0, args=0x14cfb70, nargsf=9223372036854775808, kwnames=0x0) at Objects/classobject.c:53
#581 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506bfd6b0, args=0x14cfb70, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:118
#582 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506bfd6b0, args=0x14cfb70, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#583 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834bac98, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#584 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x14cf9f0, throwflag=0) at Python/ceval.c:3490
#585 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x14cf9f0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#586 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7506f31a00, args=0x14f71a0, nargs=2, globals=0x7f75070369b0) at Objects/call.c:329
#587 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7506e86cd0, stack=0x14f7190, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#588 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506e86cd0, args=0x14f7190, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#589 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506e86cd0, args=0x14f7190, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#590 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834bc358, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#591 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x14f6fb0, throwflag=0) at Python/ceval.c:3476
#592 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x14f6fb0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#593 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506f31d40, globals=0x7f75070369b0, locals=0x0, args=0x7ffd834bda40, argcount=2, kwnames=0x0, kwargs=0x7ffd834bda50, kwcount=0, kwstep=1, defs=0x7f7506f3ba18, defcount=1, kwdefs=0x0, 
    closure=0x0, name=0x7f7507158590, qualname=0x7f7506f32b20) at Python/ceval.c:4299
#594 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506e86eb0, stack=0x7ffd834bda40, nargsf=2, kwnames=0x0) at Objects/call.c:395
#595 0x000000000063b8f8 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506e86eb0, args=0x7ffd834bda40, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#596 0x000000000063be27 in method_vectorcall (method=0x7f7506bfd4d0, args=0x7f7506c54928, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#597 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7506bfd4d0, tuple=0x7f7506c54910, kwargs=0x7f7506bfd470) at Objects/call.c:230
#598 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7506bfd4d0, args=0x7f7506c54910, kwargs=0x7f7506bfd470) at Objects/call.c:265
#599 0x00000000004311f2 in PyObject_Call (callable=0x7f7506bfd4d0, args=0x7f7506c54910, kwargs=0x7f7506bfd470) at Objects/call.c:292
#600 0x000000000051edf6 in do_call_core (tstate=0x13abcc0, func=0x7f7506bfd4d0, callargs=0x7f7506c54910, kwdict=0x7f7506bfd470) at Python/ceval.c:5092
#601 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506c00d00, throwflag=0) at Python/ceval.c:3552
#602 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506c00d00, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#603 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506f36040, globals=0x7f75070369b0, locals=0x0, args=0x7ffd834bf3d0, argcount=2, kwnames=0x0, kwargs=0x7ffd834bf3e0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f75071822e0, qualname=0x7f7506f32d00) at Python/ceval.c:4299
#604 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506e880f0, stack=0x7ffd834bf3d0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#605 0x0000000000430a42 in _PyObject_FastCallDictTstate (tstate=0x13abcc0, callable=0x7f7506e880f0, args=0x7ffd834bf3d0, nargsf=2, kwargs=0x0) at Objects/call.c:118
#606 0x0000000000431b39 in _PyObject_Call_Prepend (tstate=0x13abcc0, callable=0x7f7506e880f0, obj=0x7f7506bfbaf0, args=0x7f7506c48780, kwargs=0x0) at Objects/call.c:488
#607 0x00000000004a22b5 in slot_tp_call (self=0x7f7506bfbaf0, args=0x7f7506c48780, kwds=0x0) at Objects/typeobject.c:6663
#608 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7506bfbaf0, args=0x7f7506c019b8, nargs=1, keywords=0x0) at Objects/call.c:191
#609 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506bfbaf0, args=0x7f7506c019b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#610 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506bfbaf0, args=0x7f7506c019b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#611 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834bf688, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#612 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506c01810, throwflag=0) at Python/ceval.c:3490
#613 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506c01810, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#614 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506ef21e0, globals=0x7f7506fc4230, locals=0x0, args=0x7ffd834c0d80, argcount=2, kwnames=0x0, kwargs=0x7ffd834c0d90, kwcount=0, kwstep=1, defs=0x7f7506e8c6a8, defcount=1, kwdefs=0x0, 
    closure=0x0, name=0x7f7507158590, qualname=0x7f7506e8bc40) at Python/ceval.c:4299
#615 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506e8e870, stack=0x7ffd834c0d80, nargsf=2, kwnames=0x0) at Objects/call.c:395
#616 0x000000000063b8f8 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506e8e870, args=0x7ffd834c0d80, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#617 0x000000000063be27 in method_vectorcall (method=0x7f7506bfd3b0, args=0x7f7506c48658, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#618 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7506bfd3b0, tuple=0x7f7506c48640, kwargs=0x7f7506bfd590) at Objects/call.c:230
#619 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7506bfd3b0, args=0x7f7506c48640, kwargs=0x7f7506bfd590) at Objects/call.c:265
#620 0x00000000004311f2 in PyObject_Call (callable=0x7f7506bfd3b0, args=0x7f7506c48640, kwargs=0x7f7506bfd590) at Objects/call.c:292
#621 0x000000000051edf6 in do_call_core (tstate=0x13abcc0, func=0x7f7506bfd3b0, callargs=0x7f7506c48640, kwdict=0x7f7506bfd590) at Python/ceval.c:5092
#622 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506c00960, throwflag=0) at Python/ceval.c:3552
#623 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506c00960, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#624 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506ee9930, globals=0x7f7506fc4230, locals=0x0, args=0x7ffd834c2710, argcount=2, kwnames=0x0, kwargs=0x7ffd834c2720, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f75071822e0, qualname=0x7f7506e8b8e0) at Python/ceval.c:4299
#625 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506e8e730, stack=0x7ffd834c2710, nargsf=2, kwnames=0x0) at Objects/call.c:395
#626 0x0000000000430a42 in _PyObject_FastCallDictTstate (tstate=0x13abcc0, callable=0x7f7506e8e730, args=0x7ffd834c2710, nargsf=2, kwargs=0x0) at Objects/call.c:118
#627 0x0000000000431b39 in _PyObject_Call_Prepend (tstate=0x13abcc0, callable=0x7f7506e8e730, obj=0x7f7506bfba00, args=0x7f7506c41500, kwargs=0x0) at Objects/call.c:488
#628 0x00000000004a22b5 in slot_tp_call (self=0x7f7506bfba00, args=0x7f7506c41500, kwds=0x0) at Objects/typeobject.c:6663
#629 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7506bfba00, args=0x7f7506c017c8, nargs=1, keywords=0x0) at Objects/call.c:191
#630 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506bfba00, args=0x7f7506c017c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#631 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506bfba00, args=0x7f7506c017c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#632 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834c29c8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#633 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506c01620, throwflag=0) at Python/ceval.c:3490
#634 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506c01620, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#635 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506ef21e0, globals=0x7f7506fc4230, locals=0x0, args=0x7ffd834c40c0, argcount=2, kwnames=0x0, kwargs=0x7ffd834c40d0, kwcount=0, kwstep=1, defs=0x7f7506e8c6a8, defcount=1, kwdefs=0x0, 
    closure=0x0, name=0x7f7507158590, qualname=0x7f7506e8bc40) at Python/ceval.c:4299
#636 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506e8e870, stack=0x7ffd834c40c0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#637 0x000000000063b8f8 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506e8e870, args=0x7ffd834c40c0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#638 0x000000000063be27 in method_vectorcall (method=0x7f7506bfd2f0, args=0x7f7506c480b8, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#639 0x0000000000430f60 in PyVectorcall_Call (callable=0x7f7506bfd2f0, tuple=0x7f7506c480a0, kwargs=0x7f7506bfd290) at Objects/call.c:230
#640 0x000000000043110b in _PyObject_Call (tstate=0x13abcc0, callable=0x7f7506bfd2f0, args=0x7f7506c480a0, kwargs=0x7f7506bfd290) at Objects/call.c:265
#641 0x00000000004311f2 in PyObject_Call (callable=0x7f7506bfd2f0, args=0x7f7506c480a0, kwargs=0x7f7506bfd290) at Objects/call.c:292
#642 0x000000000051edf6 in do_call_core (tstate=0x13abcc0, func=0x7f7506bfd2f0, callargs=0x7f7506c480a0, kwdict=0x7f7506bfd290) at Python/ceval.c:5092
#643 0x0000000000519a9b in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506c00790, throwflag=0) at Python/ceval.c:3552
#644 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506c00790, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#645 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506ee9930, globals=0x7f7506fc4230, locals=0x0, args=0x7ffd834c5a50, argcount=2, kwnames=0x0, kwargs=0x7ffd834c5a60, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7f75071822e0, qualname=0x7f7506e8b8e0) at Python/ceval.c:4299
#646 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506e8e730, stack=0x7ffd834c5a50, nargsf=2, kwnames=0x0) at Objects/call.c:395
#647 0x0000000000430a42 in _PyObject_FastCallDictTstate (tstate=0x13abcc0, callable=0x7f7506e8e730, args=0x7ffd834c5a50, nargsf=2, kwargs=0x0) at Objects/call.c:118
#648 0x0000000000431b39 in _PyObject_Call_Prepend (tstate=0x13abcc0, callable=0x7f7506e8e730, obj=0x7f7506bf1910, args=0x7f7506ce3be0, kwargs=0x0) at Objects/call.c:488
#649 0x00000000004a22b5 in slot_tp_call (self=0x7f7506bf1910, args=0x7f7506ce3be0, kwds=0x0) at Objects/typeobject.c:6663
#650 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x7f7506bf1910, args=0x14efba8, nargs=1, keywords=0x0) at Objects/call.c:191
#651 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506bf1910, args=0x14efba8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#652 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506bf1910, args=0x14efba8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#653 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834c5d08, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#654 0x0000000000519407 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x14ef9b0, throwflag=0) at Python/ceval.c:3490
#655 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x14ef9b0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#656 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7506ebde10, args=0x7f7506c011e0, nargs=2, globals=0x7f7506e758f0) at Objects/call.c:329
#657 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7506dd6d70, stack=0x7f7506c011d0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#658 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506dd6d70, args=0x7f7506c011d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#659 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506dd6d70, args=0x7f7506c011d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#660 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834c73c8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#661 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x7f7506c01050, throwflag=0) at Python/ceval.c:3476
#662 0x0000000000430476 in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x7f7506c01050, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#663 0x0000000000431328 in function_code_fastcall (tstate=0x13abcc0, co=0x7f7506ea41e0, args=0x14ed098, nargs=1, globals=0x7f7506e8df50) at Objects/call.c:329
#664 0x0000000000431576 in _PyFunction_Vectorcall (func=0x7f7506dd8690, stack=0x14ed090, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#665 0x00000000005098a0 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x7f7506dd8690, args=0x14ed090, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#666 0x00000000005098ff in PyObject_Vectorcall (callable=0x7f7506dd8690, args=0x14ed090, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#667 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834c8a78, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#668 0x000000000051927c in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x14eceb0, throwflag=0) at Python/ceval.c:3476
#669 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x14eceb0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#670 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f7506e9a930, globals=0x7f7506e8df50, locals=0x0, args=0x7ffd834ca180, argcount=1, kwnames=0x0, kwargs=0x7ffd834ca188, kwcount=0, kwstep=1, defs=0x7f7506dd6f68, defcount=11, kwdefs=0x7f7506ea2e90, 
    closure=0x0, name=0x7f7507182460, qualname=0x7f7506e9ea60) at Python/ceval.c:4299
#671 0x0000000000431809 in _PyFunction_Vectorcall (func=0x7f7506dd8050, stack=0x7ffd834ca180, nargsf=1, kwnames=0x0) at Objects/call.c:395
#672 0x0000000000430a42 in _PyObject_FastCallDictTstate (tstate=0x13abcc0, callable=0x7f7506dd8050, args=0x7ffd834ca180, nargsf=1, kwargs=0x0) at Objects/call.c:118
#673 0x0000000000431b39 in _PyObject_Call_Prepend (tstate=0x13abcc0, callable=0x7f7506dd8050, obj=0x7f750703a0a0, args=0x7f7507185050, kwargs=0x0) at Objects/call.c:488
#674 0x00000000004a2969 in slot_tp_init (self=0x7f750703a0a0, args=0x7f7507185050, kwds=0x0) at Objects/typeobject.c:6903
#675 0x00000000004923ea in type_call (type=0x14a7fb0, args=0x7f7507185050, kwds=0x0) at Objects/typeobject.c:1023
#676 0x0000000000430d6d in _PyObject_MakeTpCall (tstate=0x13abcc0, callable=0x14a7fb0, args=0x140b7d8, nargs=0, keywords=0x0) at Objects/call.c:191
#677 0x0000000000509884 in _PyObject_VectorcallTstate (tstate=0x13abcc0, callable=0x14a7fb0, args=0x140b7d8, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:116
#678 0x00000000005098ff in PyObject_Vectorcall (callable=0x14a7fb0, args=0x140b7d8, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#679 0x000000000051e8c1 in call_function (tstate=0x13abcc0, pp_stack=0x7ffd834ca498, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#680 0x0000000000519210 in _PyEval_EvalFrameDefault (tstate=0x13abcc0, f=0x140b660, throwflag=0) at Python/ceval.c:3459
#681 0x0000000000509b4d in _PyEval_EvalFrame (tstate=0x13abcc0, f=0x140b660, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#682 0x000000000051cdbd in _PyEval_EvalCode (tstate=0x13abcc0, _co=0x7f750704b860, globals=0x7f75070b5050, locals=0x7f75070b5050, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#683 0x000000000051cec0 in _PyEval_EvalCodeWithName (_co=0x7f750704b860, globals=0x7f75070b5050, locals=0x7f75070b5050, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#684 0x000000000051cf48 in PyEval_EvalCodeEx (_co=0x7f750704b860, globals=0x7f75070b5050, locals=0x7f75070b5050, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#685 0x000000000050ba2f in PyEval_EvalCode (co=0x7f750704b860, globals=0x7f75070b5050, locals=0x7f75070b5050) at Python/ceval.c:809
#686 0x000000000056e8a7 in run_eval_code_obj (tstate=0x13abcc0, co=0x7f750704b860, globals=0x7f75070b5050, locals=0x7f75070b5050) at Python/pythonrun.c:1178
#687 0x000000000056e990 in run_mod (mod=0x142cb28, filename=0x7f750707f670, globals=0x7f75070b5050, locals=0x7f75070b5050, flags=0x7ffd834cbe98, arena=0x7f750704e820) at Python/pythonrun.c:1199
#688 0x000000000056e71f in PyRun_FileExFlags (fp=0x13a86a0, filename_str=0x7f7507046420 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", start=257, globals=0x7f75070b5050, locals=0x7f75070b5050, closeit=1, 
    flags=0x7ffd834cbe98) at Python/pythonrun.c:1116
#689 0x000000000056d1f5 in PyRun_SimpleFileExFlags (fp=0x13a86a0, filename=0x7f7507046420 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", closeit=1, flags=0x7ffd834cbe98) at Python/pythonrun.c:438
#690 0x000000000056c706 in PyRun_AnyFileExFlags (fp=0x13a86a0, filename=0x7f7507046420 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", closeit=1, flags=0x7ffd834cbe98) at Python/pythonrun.c:87
#691 0x000000000041e6f5 in pymain_run_file (config=0x13aa1a0, cf=0x7ffd834cbe98) at Modules/main.c:369
#692 0x000000000041ec94 in pymain_run_python (exitcode=0x7ffd834cbedc) at Modules/main.c:553
#693 0x000000000041ed85 in Py_RunMain () at Modules/main.c:632
#694 0x000000000041edff in pymain_main (args=0x7ffd834cbf40) at Modules/main.c:662
#695 0x000000000041ee79 in Py_BytesMain (argc=2, argv=0x7ffd834cc078) at Modules/main.c:686
#696 0x000000000041d796 in main (argc=2, argv=0x7ffd834cc078) at ./Programs/python.c:15
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.8-2.fc32.x86_64 glibc-2.31-2.fc32.x86_64 libffi-3.1-24.fc32.x86_64 libxcrypt-4.4.16-3.fc32.x86_64 openssl-libs-1.1.1g-1.fc32.x86_64 xz-libs-5.2.5-1.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64

----------

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

From report at bugs.python.org  Thu Jul  2 10:19:04 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Jul 2020 14:19:04 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593699544.65.0.356715037605.issue41194@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

A shorter reproducer;

>>> import sys
>>> sys.modules.clear()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: lost builtins module
>>> import _ast
>>> import gc
>>> gc.collect()
Modules/gcmodule.c:114: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small
Enable tracemalloc to get the memory block allocation traceback

object address  : 0x7f4c22f843b0
object refcount : 2
object type     : 0x5605f3385660
object type name: module
object repr     : <module '_ast' (built-in)>

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: initialized

Current thread 0x00007f4c23a5d280 (most recent call first):
  File "<stdin>", line 1 in <module>
[1]    21945 abort (core dumped)  ./python

----------

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

From report at bugs.python.org  Thu Jul  2 10:24:45 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 14:24:45 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593699885.47.0.107348939916.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

That's not an entirely accurate reproducer as the references to the modules are still held in the collection when the sys.modules.clear() is called.

----------

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

From report at bugs.python.org  Thu Jul  2 10:27:48 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 14:27:48 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593700068.69.0.0511057687211.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

> old_modules = dict(sys.modules)
> sys.modules.clear()
> sys.modules.update(old_modules)

----------

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

From report at bugs.python.org  Thu Jul  2 10:35:16 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Jul 2020 14:35:16 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593700516.98.0.174329229829.issue41194@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul  2 11:15:50 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 02 Jul 2020 15:15:50 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593702950.07.0.622643244523.issue41194@roundup.psfhosted.org>


Change by Arcadiy Ivanov <arcadiy at ivanov.biz>:


----------
components: +Interpreter Core
type:  -> crash

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

From report at bugs.python.org  Thu Jul  2 11:29:21 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Jul 2020 15:29:21 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593703761.95.0.791391033756.issue41194@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

If I'm not wrong, this is the commit that introduced the regression.

commit ac46eb4ad6662cf6d771b20d8963658b2186c48c (HEAD -> bpo-xxxxx)
Author: Dino Viehland <dinoviehland at fb.com>
Date:   Wed Sep 11 10:16:34 2019 -0700

    bpo-38113: Update the Python-ast.c generator to PEP384 (gh-15957)
    
    Summary: This mostly migrates Python-ast.c to PEP384 and removes all statics from the whole file. This modifies the generator itself that generates the Python-ast.c. It leaves in the usage of _PyObject_LookupAttr even though it's not fully PEP384 compatible (this could always be shimmed in by anyone who needs it).

----------
nosy: +dino.viehland

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

From report at bugs.python.org  Thu Jul  2 11:34:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 15:34:48 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593704088.95.0.359343404151.issue41194@roundup.psfhosted.org>


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

I can reproduce the crash using the following script.py:
---
import gc; gc.set_threshold(5)
import sys

old_modules = dict(sys.modules)
sys.modules.clear()
sys.modules.update(old_modules)

import _ast
import gc
gc.collect()
---

And the command:
---
./python -i < script.py
---

PyInit__ast() is called twice. That's surprising: builtin extension modules should only be initialized once.

----------

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

From report at bugs.python.org  Thu Jul  2 12:13:19 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Jul 2020 16:13:19 +0000
Subject: [issue41073] [C API] PyType_GetSlot() should accept static types
In-Reply-To: <1592815094.33.0.264745776024.issue41073@roundup.psfhosted.org>
Message-ID: <1593706399.72.0.861731301982.issue41073@roundup.psfhosted.org>


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

> You'll probably need some table like typeslots.inc to record which sub-slots struct each slot belongs to.

Looks like it's a good way to solve this probleam, Let me try it ;)

----------

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

From report at bugs.python.org  Thu Jul  2 12:54:51 2020
From: report at bugs.python.org (Steve Bowman)
Date: Thu, 02 Jul 2020 16:54:51 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1593708891.87.0.855231890802.issue32958@roundup.psfhosted.org>


Steve Bowman <sdbowman at allwest.net> added the comment:

When will this issue be fixed?  Thanks!

----------
nosy: +sdbowman

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

From report at bugs.python.org  Thu Jul  2 13:08:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2020 17:08:43 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593709723.82.0.762182067181.issue41194@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jul  2 13:40:49 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Thu, 02 Jul 2020 17:40:49 +0000
Subject: [issue41139] cgi uses the locale encoding for log files
In-Reply-To: <1593257405.62.0.0746372218017.issue41139@roundup.psfhosted.org>
Message-ID: <1593711649.04.0.606606523123.issue41139@roundup.psfhosted.org>


Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com> added the comment:

I am for keeping this functionality. Unless others in this nosy list think otherwise.

----------
nosy: +thatiparthy

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

From report at bugs.python.org  Thu Jul  2 13:46:13 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 02 Jul 2020 17:46:13 +0000
Subject: [issue41139] cgi uses the locale encoding for log files
In-Reply-To: <1593257405.62.0.0746372218017.issue41139@roundup.psfhosted.org>
Message-ID: <1593711973.78.0.160285934493.issue41139@roundup.psfhosted.org>


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

Which functionality?

- cgi.log()

- opening with current locale

I don't mind keeping the function, but if the file isn't already opened I think using UTF-8 is an appropriate choice.

----------

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

From report at bugs.python.org  Thu Jul  2 14:06:42 2020
From: report at bugs.python.org (aku911)
Date: Thu, 02 Jul 2020 18:06:42 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
Message-ID: <1593713202.41.0.223352950453.issue41196@roundup.psfhosted.org>


Change by aku911 <aku911 at gmail.com>:


----------
components: Windows
nosy: aku911, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: APPDATA directory is different in store installed python
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Jul  2 14:08:03 2020
From: report at bugs.python.org (aku911)
Date: Thu, 02 Jul 2020 18:08:03 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
Message-ID: <1593713283.65.0.795471519657.issue41196@roundup.psfhosted.org>


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

Install the windows store python then run this code:

import os
os.listdir(os.environ['APPDATA'])

Install another version of python and run the same code.

You'll get different results.

This can cause issues when trying to share data in a user's APPDATA folder.

----------

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

From report at bugs.python.org  Thu Jul  2 14:09:16 2020
From: report at bugs.python.org (aku911)
Date: Thu, 02 Jul 2020 18:09:16 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
In-Reply-To: <1593713283.65.0.795471519657.issue41196@roundup.psfhosted.org>
Message-ID: <1593713356.86.0.0230500376935.issue41196@roundup.psfhosted.org>


aku911 <aku911 at gmail.com> added the comment:

This is causing this issue here:
https://github.com/microsoft/vscode-python/issues/11412

----------

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

From report at bugs.python.org  Thu Jul  2 14:11:27 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Thu, 02 Jul 2020 18:11:27 +0000
Subject: [issue41139] cgi uses the locale encoding for log files
In-Reply-To: <1593257405.62.0.0746372218017.issue41139@roundup.psfhosted.org>
Message-ID: <1593713487.04.0.369593966391.issue41139@roundup.psfhosted.org>


Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com> added the comment:

My bad. I meant cgi.log(), I pressed submit changes in a hurry.

+1 for utf-8.

----------

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

From report at bugs.python.org  Thu Jul  2 14:22:53 2020
From: report at bugs.python.org (=?utf-8?b?0KDQsNC80LfQsNC9INCRLg==?=)
Date: Thu, 02 Jul 2020 18:22:53 +0000
Subject: [issue41197] Async magic methods in contextlib.closing
Message-ID: <1593714173.91.0.0149218020987.issue41197@roundup.psfhosted.org>


New submission from ?????? ?. <uburuntu at gmail.com>:

# Async magic methods in contextlib.closing

I think `__aenter__` and `__aexit__` methods should be added to `contextlib.closing`, so that we can use `contextlib.closing` in async code too.

For example:

```python3
class SomeAPI:
    ...

    async def request(self):
        pass

    async def close(self):
        await self.session.close()
        

async with closing(SomeAPI()) as api:
    response = await api.request()
    print(response)
```

Also these methods can be moved to another class (like `asyncclosing` along the lines of `asynccontextmanager`).

----------
components: Library (Lib)
messages: 372871
nosy: ?????? ?.
priority: normal
pull_requests: 20434
severity: normal
status: open
title: Async magic methods in contextlib.closing
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Jul  2 14:34:44 2020
From: report at bugs.python.org (Simon Charette)
Date: Thu, 02 Jul 2020 18:34:44 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1593714884.14.0.253992524306.issue12029@roundup.psfhosted.org>


Change by Simon Charette <charette.s at gmail.com>:


----------
nosy: +charettes

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

From report at bugs.python.org  Thu Jul  2 14:39:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Jul 2020 18:39:39 +0000
Subject: [issue41197] Async magic methods in contextlib.closing
In-Reply-To: <1593714173.91.0.0149218020987.issue41197@roundup.psfhosted.org>
Message-ID: <1593715179.51.0.374679932407.issue41197@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +yselivanov

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

From report at bugs.python.org  Thu Jul  2 14:49:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 18:49:44 +0000
Subject: [issue41139] cgi uses the locale encoding for log files
In-Reply-To: <1593257405.62.0.0746372218017.issue41139@roundup.psfhosted.org>
Message-ID: <1593715784.77.0.528963532751.issue41139@roundup.psfhosted.org>


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

Available options:

1. Do nothing (keep cgi.log() and continue to use the default encoding for open()).
2. Remove cgi.log(). I think that the deprecation period is not needed because the function is not documented, is not imported by star-import, and is not shown in help.
3. Make cgi.log() using UTF-8 for open(). This may break some existing code if cgi.log() is ever used.
4. Completely rewrite cgi.log() using the logging module.

In all options except 2 cgi.log() needs to be documented and advertised as a new feature. And we should ask ourself: do we need this feature? Does it have advantages over the logging package?

It was more visible in 2.0. But since adding __all__ in 2.1 (in e99d5ea25ba994491c773d9b5872332334ccd1c5) it is a hidden feature.

----------

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

From report at bugs.python.org  Thu Jul  2 15:03:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jul 2020 19:03:00 +0000
Subject: [issue41197] Async magic methods in contextlib.closing
In-Reply-To: <1593714173.91.0.0149218020987.issue41197@roundup.psfhosted.org>
Message-ID: <1593716580.99.0.92861608258.issue41197@roundup.psfhosted.org>


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

And what happen when you accidentally use synchronous "with" instead of "async with" with closing()?

with closing(SomeAPI()) as api:
    ...

I think it is intentionally that different functions/methods/classes are used for synchronous and asynchronous operations.

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

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

From report at bugs.python.org  Thu Jul  2 15:10:32 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 02 Jul 2020 19:10:32 +0000
Subject: [issue33665] tkinter.ttk.Scrollbar.fraction() under-estimates length
In-Reply-To: <1527503945.83.0.682650639539.issue33665@psf.upfronthosting.co.za>
Message-ID: <1593717032.77.0.0202302675574.issue33665@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I agree that the `tkinter.ttk.Scrollbar.fraction` under-estimates the length of the trough and I have written a program to try to measure this precisely.

When tested (only on Linux, granted), this deficit was measured to be 9 pixels (unless I got the maths wrong!). Tcl/Tk gave **exactly** the same numbers when run using 'wish'.

Thank you pez for reporting this, but 2 years on it should be closed as third party (please do take it up with the tcl team if you feel it is a real issue).

----------
nosy: +epaine
title: tkinter.ttk.Scrollbar.fraction() is inaccurate, or at least inconsistent compared to the non ttk version -> tkinter.ttk.Scrollbar.fraction() under-estimates length
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7
Added file: https://bugs.python.org/file49292/ttkscrl.py

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

From report at bugs.python.org  Thu Jul  2 15:10:38 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 02 Jul 2020 19:10:38 +0000
Subject: [issue33665] tkinter.ttk.Scrollbar.fraction() under-estimates length
In-Reply-To: <1527503945.83.0.682650639539.issue33665@psf.upfronthosting.co.za>
Message-ID: <1593717038.0.0.342843196002.issue33665@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


Added file: https://bugs.python.org/file49293/ttkscrl.tcl

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

From report at bugs.python.org  Thu Jul  2 15:37:33 2020
From: report at bugs.python.org (Ramzan Bekbulatov)
Date: Thu, 02 Jul 2020 19:37:33 +0000
Subject: [issue41197] Async magic methods in contextlib.closing
In-Reply-To: <1593714173.91.0.0149218020987.issue41197@roundup.psfhosted.org>
Message-ID: <1593718653.77.0.225340062457.issue41197@roundup.psfhosted.org>


Ramzan Bekbulatov <uburuntu at gmail.com> added the comment:

In this case:

```python3
class A:
    async def close(self):
        pass
    
with closing(A()):
    pass
```

Python will raise `RuntimeWarning: coroutine 'A.close' was never awaited`.

In another case:

```python3
class B:
    def close(self):
        pass
    
async with closing(B()):
    pass
```

Python will raise `TypeError: object NoneType can't be used in 'await' expression` (because it will try to await result of close method).

-----

I was surprised that `contextlib` has no async analogue of this `closing` class, because async scripts often use any kind of closings. Do you think it's better to extract to `asyncclosing` class?

----------

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

From report at bugs.python.org  Thu Jul  2 15:51:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Jul 2020 19:51:16 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593719476.03.0.0179424459226.issue41180@roundup.psfhosted.org>


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

Actually, a quick search of codeobject.c and a look at tkmk's PR makes it seem like the audit event should be being raised from inside PyCode_NewWithPosOnlyArgs anyway (which IIRC didn't exist when I first added the event, though it was probably there before it was merged).

In general, events should be raised after parameters have been validated, but before any work is done. And when all the other calls feed through a single function, just auditing that one function is enough.

----------

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

From report at bugs.python.org  Thu Jul  2 16:05:45 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 02 Jul 2020 20:05:45 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1593720345.45.0.0154107316613.issue38980@roundup.psfhosted.org>


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

Yes this should become part of --with-optimizations when building on a platform using a compiler that (a) supports it and (b) where it matters.

If this is only relevant on --enable-shared builds (not the default), i'd assume also make it conditional on that.

I never use --enable-shared builds myself.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Thu Jul  2 16:06:26 2020
From: report at bugs.python.org (Carlos Neves)
Date: Thu, 02 Jul 2020 20:06:26 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
Message-ID: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>


New submission from Carlos Neves <caneves at gmail.com>:

Hi,

I am observing unexpected behavior with round built-in function about (1) significant figures in analytical methods and (2) number of odd and even numbers obtained by this function.

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

https://en.wikipedia.org/wiki/Significant_figures

1. Significant Figures
======================

For example, when I say 1.20 in analytical methods, I am confident about the last digit, the zero. It has a meaning. But, when I use Python,

>>> round (1.203, 2)
1.2
>>>

the zero not appears. It is not occur when the second digit is not zero. 

>>> round (1.213, 2)
1.21
>>>

The zero should be printed like the other numbers to be consistent with the significant figures. Maybe other functions could present the same behavior.

2. Rounding procedure
=====================

I wrote the following code to test the number of odd and even numbers during a round procedure. I should get half-and-a-half of odd and even numbers. But the result using the round function is different. We observed 5 even more and 5 odd less. This behavior causes a systematic error.

https://en.wikipedia.org/wiki/Rounding

I hope to be contributing to the improvement of the code.

Thank advanced.


######################################################
# This code count the number of odd and even number with different procedures: truncate, round simple and round function 
# Test condition: Rounding with one digit after the decimal point.

import numpy as np

even_0 = 0
odd_0 = 0

even_1 = 0
odd_1 = 0

even_2 = 0
odd_2 = 0

even_3 = 0
odd_3 = 0

# generate 1000 numbers from 0.000 up to 1 with step of 0.001
x = np.arange(0,1,0.001) 

# printing 
for i in range(len(x)): 

	x_truncated = int((x[i]*10)+0.0)/10 # no rounding
	x_rounded_simple = int((x[i]*10)+0.5)/10 # rounding up at 5
	x_rounded_function = round(x[i],1) # rounding by function with one digit after the decimal point

	# counting odd and even numbers
	if int(x[i]*1000) % 2 == 0:
		even_0 += 1
	else:
		odd_0 += 1

	if int(x_truncated*10) % 2 == 0:
		even_1 += 1
	else:
		odd_1 += 1

	if int(x_rounded_simple*10) % 2 == 0:
		even_2 += 1
	else:
		odd_2 += 1

	if int(x_rounded_function*10) % 2 == 0:
		even_3 += 1
	else:
		odd_3 += 1

	print ("{0:.3f} {1:.1f} {2:.1f} {3:.1f}".format((x[i]), x_truncated, x_rounded_simple, x_rounded_function))

print ("Result:")
print ("Raw: Even={0}, Odd={1}".format(even_0,odd_0))	
print ("Truncated: Even={0}, Odd={1}".format(even_1,odd_1))
print ("Rounded simple: Even={0}, Odd={1}".format(even_2,odd_2))
print ("Rounded Function: Even={0}, Odd={1}".format(even_3,odd_3))

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

Output
...
0.995 0.9 1.0 1.0
0.996 0.9 1.0 1.0
0.997 0.9 1.0 1.0
0.998 0.9 1.0 1.0
0.999 0.9 1.0 1.0
Result:
Raw: Even=500, Odd=500
Truncated: Even=500, Odd=500
Rounded simple: Even=500, Odd=500
Rounded Function: Even=505, Odd=495

----

----------
components: Library (Lib)
messages: 372878
nosy: Carlos Neves, lemburg, mark.dickinson, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: Round built-in function not shows zeros acording significant figures and calculates different numbers of odd and even
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Jul  2 16:06:53 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 02 Jul 2020 20:06:53 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1593720413.85.0.530939203551.issue38980@roundup.psfhosted.org>


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

and to echo others: Do not worry about LD_PRELOAD users trying to override internals.  That is not a supported use case.  It is always a hack.  anyone using it knows this.

----------

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

From report at bugs.python.org  Thu Jul  2 16:25:57 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Jul 2020 20:25:57 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
In-Reply-To: <1593713283.65.0.795471519657.issue41196@roundup.psfhosted.org>
Message-ID: <1593721557.83.0.144374581568.issue41196@roundup.psfhosted.org>


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

This is by (Windows's) design - separate apps are treated as separate by the Windows app model. In the latest and N-1 updates to Windows, the AppData redirection only applies to newly created files, not those that already exist. [1] Before then, it used copy-on-write.

The design is based on having seen many apps break because of inadvertently sharing data, and also apps failing to clean up after themselves well (of which Python is *very* guilty). The built-in "Reset App" and "Uninstall App" functions would not be viable without this separation.

What it really means for apps that are trying to share state across different Python runtimes is that they're not going to have such a great time. The best option I can offer is to use the user's Documents folder instead, which is explicitly shared (though may also be synced between machines, so not always appropriate).

The next best option is to recommend that the Store package only be used on its own, and not in conjunction with other Python installs. Those who need multiple versions or mostly-but-not-quite-separate installs will need to use the traditional installer.

But what it means for all the other tools that write to AppData is that they don't have to worry about old settings laying around or causing additional clutter. The standard "Reset app" action is a viable way to fix issues in configuration or cached files (and uninstall all packages). From a user point of view, I really like these features.

1: https://docs.microsoft.com/windows/msix/desktop/desktop-to-uwp-behind-the-scenes

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

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

From report at bugs.python.org  Thu Jul  2 16:26:50 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Jul 2020 20:26:50 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
In-Reply-To: <1593713283.65.0.795471519657.issue41196@roundup.psfhosted.org>
Message-ID: <1593721610.16.0.0173411626885.issue41196@roundup.psfhosted.org>


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

As an aside, virtual environments will have the same redirection as the base interpreter, so this is really only an issue between a 3.7 install and a 3.8 install, or a Store install and a traditional install.

----------

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

From report at bugs.python.org  Thu Jul  2 16:31:27 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 02 Jul 2020 20:31:27 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593721886.99.0.59810025716.issue39960@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think we missed the train for fixing 3.7 (which was questionable anyway), but I added a test, so it's ready for merging into 3.8+ (minus merge conflicts for the test in 3.8, probably).

----------

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

From report at bugs.python.org  Thu Jul  2 16:54:35 2020
From: report at bugs.python.org (Michael DePalatis)
Date: Thu, 02 Jul 2020 20:54:35 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1593723275.12.0.189132976342.issue41177@roundup.psfhosted.org>


Michael DePalatis <mike at depalatis.net> added the comment:

I think the other issue here is that the ConvertingX classes aren't documented apart from comments in the code where they are defined.

----------
nosy: +mivade

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

From report at bugs.python.org  Thu Jul  2 17:22:30 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 02 Jul 2020 21:22:30 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593724950.64.0.0272976843453.issue41198@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

For the first, your hardware's binary floating-point has no concept of significant trailing zeroes. If you need such a thing, use Python's `decimal` module instead, which does support a "significant trailing zero" concept. You would need an entirely new data type to graft such a notion onto Python's (or numpy's!) binary floats.

For the second, we'd have to dig into exactly what numpy's `arange()` does. Very few of the numbers you're working with are exactly representable in binary floating point except for 0.0. For example, "0.001" is approximated by a binary float whose exact decimal value is

0.001000000000000000020816681711721685132943093776702880859375

Sometimes the rounded (by machine float arithmetic) multiples of that are exactly representable, but usually not. For example,

>>> 0.001 * 250
0.25

rounds to the exactly representable 1/4, and

>>> 0.001 * 750
0.75

to the exactly representable 3/4. However, `round()` uses round-to-nearest/even, and then

>>> round(0.25, 1)
0.2
>>> round(0.75, 1)
0.8

both resolve the tie to the closest even value (although neither of those _results_ are exactly representable in binary floating-point - although if you go on to multiply them by 10.0, they do round (in hardware) to exactly 2.0 and 8.0).

Note that numpy's arange() docs do warn you against using it ;-)

"""
When using a non-integer step, such as 0.1, the results will often not be consistent. It is better to use numpy.linspace for these cases.
"""

----------
nosy: +tim.peters

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

From report at bugs.python.org  Thu Jul  2 17:26:59 2020
From: report at bugs.python.org (Roy Smith)
Date: Thu, 02 Jul 2020 21:26:59 +0000
Subject: [issue35105] Document that CPython accepts "invalid" identifiers
In-Reply-To: <1540815891.13.0.788709270274.issue35105@psf.upfronthosting.co.za>
Message-ID: <1593725219.99.0.372680081376.issue35105@roundup.psfhosted.org>


Roy Smith <roy at panix.com> added the comment:

Just as another edge case, type() can do the same thing:

Foo = type("Foo", (object,), {"a b": 1})
f = Foo()

for example, will create a class attribute named "a b".  Maybe this actually calls setattr() under the covers, but if it's going to be documented, it should be noted in both places.

----------
nosy: +roysmith

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

From report at bugs.python.org  Thu Jul  2 17:45:37 2020
From: report at bugs.python.org (Carlos Neves)
Date: Thu, 02 Jul 2020 21:45:37 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593724950.64.0.0272976843453.issue41198@roundup.psfhosted.org>
Message-ID: <CAJAjSpbr6r=qEoLeg0PKvgzN5w26J=dYMLMEiv8cx32wGxO3Pw@mail.gmail.com>


Carlos Neves <caneves at gmail.com> added the comment:

Hi Peters,

I will pay more attention to the Python docs :)
Thank you for your direction.

Carlos A. Neves

Em qui., 2 de jul. de 2020 ?s 18:22, Tim Peters
<report at bugs.python.org> escreveu:
>
>
> Tim Peters <tim at python.org> added the comment:
>
> For the first, your hardware's binary floating-point has no concept of significant trailing zeroes. If you need such a thing, use Python's `decimal` module instead, which does support a "significant trailing zero" concept. You would need an entirely new data type to graft such a notion onto Python's (or numpy's!) binary floats.
>
> For the second, we'd have to dig into exactly what numpy's `arange()` does. Very few of the numbers you're working with are exactly representable in binary floating point except for 0.0. For example, "0.001" is approximated by a binary float whose exact decimal value is
>
> 0.001000000000000000020816681711721685132943093776702880859375
>
> Sometimes the rounded (by machine float arithmetic) multiples of that are exactly representable, but usually not. For example,
>
> >>> 0.001 * 250
> 0.25
>
> rounds to the exactly representable 1/4, and
>
> >>> 0.001 * 750
> 0.75
>
> to the exactly representable 3/4. However, `round()` uses round-to-nearest/even, and then
>
> >>> round(0.25, 1)
> 0.2
> >>> round(0.75, 1)
> 0.8
>
> both resolve the tie to the closest even value (although neither of those _results_ are exactly representable in binary floating-point - although if you go on to multiply them by 10.0, they do round (in hardware) to exactly 2.0 and 8.0).
>
> Note that numpy's arange() docs do warn you against using it ;-)
>
> """
> When using a non-integer step, such as 0.1, the results will often not be consistent. It is better to use numpy.linspace for these cases.
> """
>
> ----------
> nosy: +tim.peters
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41198>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Jul  2 17:45:53 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 02 Jul 2020 21:45:53 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593726353.65.0.676483686312.issue41198@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Thank you for your long and detailed bug report, but please post one issue per bug report.

Tim, we agree that the notion of significant figures is irrelevant; is Carlos' even/odd test sufficiently flawed that we should close this bug report, or keep it open to investigate the rounding bias issue? My feeling is that it is sufficiently flawed that we can just close this, but it's too early in the morning for me to articulate why :-)

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Thu Jul  2 17:56:36 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 02 Jul 2020 21:56:36 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593726996.51.0.209433996335.issue41198@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I assumed Mark would tell us what's up with the arange() oddity, so let's see whether he does.  There is no truly good way to generate "evenly spaced" binary floats using a non-representable conceptual decimal delta.  The dumbass ;-) way doesn't show a discrepancy in pure Python:

>>> num = ne = no = 0
>>> d = 0.001
>>> while num < 1.0:
...     digit = int(round(num, 1) * 10)
...     if digit & 1:
...         no += 1
...     else:
...         ne += 1
...     num += d
>>> ne, no
(500, 500)

However, a somewhat less naive way does show a discrepancy, but less so than what arange() apparently does:

>>> ne = no = 0
>>> for i in range(1000):
...     digit = int(round(i * d, 1) * 10)
...     if digit & 1:
...         no += 1
...     else:
...         ne += 1
>>> ne, no
(501, 499)

I assume that's because of the specific nearest/even behavior I already showed for multipliers i=250 and i=750.

----------

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

From report at bugs.python.org  Thu Jul  2 18:10:37 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Thu, 02 Jul 2020 22:10:37 +0000
Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult
In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>
Message-ID: <1593727837.46.0.189501987052.issue17805@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

The documentation here: https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing.pool
says that apply_async is "A variant of the apply() method which returns a result object."
You should replace "a result object" with "a AsyncResult/ApplyResult object" and a link to https://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult

----------
nosy: +Volker Wei?mann
versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jul  2 18:11:37 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 02 Jul 2020 22:11:37 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593727897.38.0.0390748812536.issue41198@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

If you change the starting point of the rounding away from zero, the bias flips back and forth, which is exactly what I would expect from Banker's Rounding:


    def check_bias(start):
        d = 0.001
        ne = no = 0
        for i in range(1000):
            digit = int(round(start + i * d, 1) * 10)
            if digit & 1:
                no += 1
            else:
                ne += 1
        return ne, no


    # Python 3.7
    >>> check_bias(0.0)
    (501, 499)
    >>> check_bias(0.1)
    (500, 500)
    >>> check_bias(0.2)
    (499, 501)
    >>> check_bias(0.3)
    (499, 501)
    >>> check_bias(0.4)
    (500, 500)
    >>> check_bias(0.5)
    (499, 501)
    >>> check_bias(0.6)
    (501, 499)


I ran the same check_bias in Python 2.7, which doesn't use bankers rounding, and the bias is consistently in one direction:

    # Python 2.7
    >>> check_bias(0.0)
    (500, 500)
    >>> check_bias(0.1)
    (499, 501)
    >>> check_bias(0.2)
    (498, 502)
    >>> check_bias(0.3)
    (498, 502)
    >>> check_bias(0.4)
    (499, 501)
    >>> check_bias(0.5)
    (498, 502)
    >>> check_bias(0.6)
    (500, 500)

----------

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

From report at bugs.python.org  Thu Jul  2 18:12:36 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 02 Jul 2020 22:12:36 +0000
Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult
In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>
Message-ID: <1593727956.37.0.527936165907.issue17805@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Volker Wei?mann, this issue has been closed for 7 years, if you want to propose a change, please open a new issue.

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Thu Jul  2 18:47:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Jul 2020 22:47:13 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593730033.27.0.769097035266.issue41162@roundup.psfhosted.org>


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

PR 21222 (with test updates) is a good fix, though we know there can still be arbitrary code executed afterwards. But it's not in a place where we can reliably hook.

Probably the best thing to do is to make sure that events are raised for anything that would be required to add code there. Though that may not be feasible either, but since nobody should be doing that kind of thing deliberately, detection is just as valuable as prevention.

----------

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

From report at bugs.python.org  Thu Jul  2 19:39:59 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Thu, 02 Jul 2020 23:39:59 +0000
Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult
In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>
Message-ID: <1593733199.58.0.290764213678.issue17805@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

Tomorror, or in a few days, I'm gonna create a pullrequest for it.

----------

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

From report at bugs.python.org  Thu Jul  2 20:09:27 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 03 Jul 2020 00:09:27 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593734967.23.0.111145515631.issue41198@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Cool! So the only thing surprising to me here is just how far off balance the arange() run was.  So I'd like to keep this open long enough for Mark to notice, just in case it's pointing to something fishy in numpy.

----------

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

From report at bugs.python.org  Thu Jul  2 20:09:32 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 00:09:32 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593734972.7.0.973444623718.issue39960@roundup.psfhosted.org>


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


New changeset 148f32913573c29250dfb3f0d079eb8847633621 by scoder in branch 'master':
bpo-39960: Allow heap types in the "Carlo Verre" hack check that override "tp_setattro()" (GH-21092)
https://github.com/python/cpython/commit/148f32913573c29250dfb3f0d079eb8847633621


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

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

From report at bugs.python.org  Thu Jul  2 20:09:58 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 00:09:58 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593734998.65.0.410197511274.issue39960@roundup.psfhosted.org>


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


----------
pull_requests: +20435
pull_request: https://github.com/python/cpython/pull/21288

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

From report at bugs.python.org  Thu Jul  2 20:13:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 03 Jul 2020 00:13:01 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593735181.25.0.57018635898.issue39960@roundup.psfhosted.org>


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

Stefan can you do the 3.8 backport?

----------

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

From report at bugs.python.org  Thu Jul  2 20:26:09 2020
From: report at bugs.python.org (Wator Sead)
Date: Fri, 03 Jul 2020 00:26:09 +0000
Subject: [issue41169] socket.inet_pton raised when pass an IPv6 address like
 "[::]" to it
In-Reply-To: <1593525971.46.0.103341919582.issue41169@roundup.psfhosted.org>
Message-ID: <1593735969.1.0.194440608454.issue41169@roundup.psfhosted.org>


Wator Sead <seahoh at gmail.com> added the comment:

The point is square brackets, not the address, they (socket.inet_pton and socket.socket) behave different. Can make it not be accepted, any conditions?

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

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

From report at bugs.python.org  Thu Jul  2 20:28:50 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 00:28:50 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593736130.63.0.0636071872622.issue39960@roundup.psfhosted.org>


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


New changeset bfec674254ea22ef9c0c335587eb65683f4145c7 by Miss Islington (bot) in branch '3.9':
bpo-39960: Allow heap types in the "Carlo Verre" hack check that override "tp_setattro()" (GH-21092)
https://github.com/python/cpython/commit/bfec674254ea22ef9c0c335587eb65683f4145c7


----------

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

From report at bugs.python.org  Thu Jul  2 21:10:13 2020
From: report at bugs.python.org (Jackstraw)
Date: Fri, 03 Jul 2020 01:10:13 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
Message-ID: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>


New submission from Jackstraw <jab1995 at gmail.com>:

The InventoryItem class on the dataclasses page [https://docs.python.org/3.7/library/dataclasses.html#module-dataclasses] has single quotes for the docstring, as opposed to double quotes (as described by PEP-257.

----------
assignee: docs at python
components: Documentation
messages: 372899
nosy: JackStraw, docs at python
priority: normal
severity: normal
status: open
title: Docstring convention not followed for dataclasses documentation page
type: enhancement
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jul  2 22:41:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Jul 2020 02:41:14 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1593744074.53.0.425660221039.issue41199@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul  2 23:08:53 2020
From: report at bugs.python.org (Yunfan Zhan)
Date: Fri, 03 Jul 2020 03:08:53 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593745733.66.0.460223189889.issue41180@roundup.psfhosted.org>


Yunfan Zhan <yfzhan at sjtu.edu.cn> added the comment:

Before this, we only audit code.__new__ and code.replace, as these methods allow constructing arbitrary code objects, and we don't audit code object coming from the normal way (like compile,exec,eval).
If the event is raised in PyCode_NewWithPosOnlyArgs, is it ok that the compiled code is also audited?

----------

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

From report at bugs.python.org  Thu Jul  2 23:14:45 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 03 Jul 2020 03:14:45 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593746085.12.0.193252032435.issue41165@roundup.psfhosted.org>


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

Hmm.  You are right. The warnings are shown by default.

On the other hand, some project uses custom `setup.py test` command. It hides the DeprecationWarning.

https://github.com/warner/python-ed25519/blob/master/setup.py
https://github.com/warner/python-ed25519/blob/master/src/ed25519/test_ed25519.py#L42

How about emitting FutureWarning instead of DeprecationWarning?

DeprecationWarning is hidden to avoid end users see noisy warnings.
But test is for developers, not end users.

----------

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

From report at bugs.python.org  Fri Jul  3 00:07:06 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 03 Jul 2020 04:07:06 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
In-Reply-To: <1593713283.65.0.795471519657.issue41196@roundup.psfhosted.org>
Message-ID: <1593749226.0.0.674124080074.issue41196@roundup.psfhosted.org>


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

> What it really means for apps that are trying to share state across
> different Python runtimes is that they're not going to have such a 
> great time.

I tried impersonating the token of Explorer in the current thread (i.e. GetShellWindow, GetWindowThreadProcessId, OpenProcess, OpenProcessToken, ImpersonateLoggedOnUser), but writing to AppData was still redirected. Apparently redirection for apps only looks at the process token. A crude workaround is to script PowerShell or CMD in a child process.

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

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

From report at bugs.python.org  Fri Jul  3 00:34:27 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Jul 2020 04:34:27 +0000
Subject: [issue41197] Async magic methods in contextlib.closing
In-Reply-To: <1593714173.91.0.0149218020987.issue41197@roundup.psfhosted.org>
Message-ID: <1593750867.86.0.656729126768.issue41197@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be a duplicate of issue40213 with a link to implementation in trio.

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Jul  3 01:15:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Jul 2020 05:15:01 +0000
Subject: [issue41197] Async magic methods in contextlib.closing
In-Reply-To: <1593714173.91.0.0149218020987.issue41197@roundup.psfhosted.org>
Message-ID: <1593753301.24.0.761012437216.issue41197@roundup.psfhosted.org>


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

Warning is not error. It may left unnoticed, especially if the code is executed on server. And in this particular case turning the warning into exception by setting warning filters does not help, because it would be raised in the context where exceptions are swallowed.

----------

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

From report at bugs.python.org  Fri Jul  3 01:22:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Jul 2020 05:22:18 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1593753738.45.0.314078368824.issue40213@roundup.psfhosted.org>


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

Do you have use cases or want to add it for pure "symmetry" reasons?

contextlib.closing() was added when context managers were new, and many classes that own resources did have the close() method but did not support the context manager protocol. Now most of these classes are context managers, and new classes usually are written with the support of  the context manager protocol from beginning. The usefulness of contextlib.closing() is much smaller now.

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

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

From report at bugs.python.org  Fri Jul  3 01:26:08 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Jul 2020 05:26:08 +0000
Subject: [issue41066] Update documentation for Pathlib
In-Reply-To: <1592756539.0.0.672795473082.issue41066@roundup.psfhosted.org>
Message-ID: <1593753968.28.0.928347170998.issue41066@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


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

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

From report at bugs.python.org  Fri Jul  3 01:31:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Jul 2020 05:31:48 +0000
Subject: [issue33665] tkinter.ttk.Scrollbar.fraction() under-estimates length
In-Reply-To: <1527503945.83.0.682650639539.issue33665@psf.upfronthosting.co.za>
Message-ID: <1593754308.44.0.644538688515.issue33665@roundup.psfhosted.org>


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

Thank you for testing it E. Paine. I agree that it is not a Tkinter issue.

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

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

From report at bugs.python.org  Fri Jul  3 01:41:06 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jul 2020 05:41:06 +0000
Subject: [issue896330] pyconfig.h is not placed in --includedir
Message-ID: <1593754866.06.0.65949614751.issue896330@roundup.psfhosted.org>


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


----------
Removed message: https://bugs.python.org/msg372730

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

From report at bugs.python.org  Fri Jul  3 01:43:58 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jul 2020 05:43:58 +0000
Subject: [issue896330] pyconfig.h is not placed in --includedir
Message-ID: <1593755038.52.0.965469115072.issue896330@roundup.psfhosted.org>


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


----------
nosy:  -Mario Gonzalez

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

From report at bugs.python.org  Fri Jul  3 02:24:07 2020
From: report at bugs.python.org (Hubert Pineault)
Date: Fri, 03 Jul 2020 06:24:07 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1593757447.97.0.915500181106.issue38731@roundup.psfhosted.org>


Hubert Pineault <hpineault at riseup.net> added the comment:

The bug is still there in python 3.8.4rc1
It has nothing to do with the doc.

As pointed by Kaoru, it is introduced in line 200 of commit 2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1

see this comment, also by Kaoru:
https://github.com/python/cpython/commit/2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1#r35842880

----------
nosy: +hubide
versions:  -Python 3.9

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

From report at bugs.python.org  Fri Jul  3 03:31:45 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 03 Jul 2020 07:31:45 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1593761505.11.0.770923800116.issue40213@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

They are both still useful, particularly with third party libraries. Just yesterday I found myself looking for aclosing() in contextlib, only to remember this issue.

----------

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

From report at bugs.python.org  Fri Jul  3 03:54:37 2020
From: report at bugs.python.org (John Belmonte)
Date: Fri, 03 Jul 2020 07:54:37 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1593762877.43.0.0585883672191.issue40213@roundup.psfhosted.org>


John Belmonte <john at neggie.net> added the comment:

Given the lack of deterministic cleanup for iterators (https://www.python.org/dev/peps/pep-0533/), aclosing() is the way to ensure deterministic cleanup given any API using async iteration.

----------

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

From report at bugs.python.org  Fri Jul  3 03:55:36 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jul 2020 07:55:36 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1593762936.3.0.269900929908.issue41199@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +20436
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21289

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

From report at bugs.python.org  Fri Jul  3 04:00:20 2020
From: report at bugs.python.org (John Belmonte)
Date: Fri, 03 Jul 2020 08:00:20 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1593763220.26.0.0264800451772.issue40213@roundup.psfhosted.org>


John Belmonte <john at neggie.net> added the comment:

highlighting from PEP 533:

> Async generators cannot do cleanup at all without some mechanism for deterministic cleanup that people will actually use, and async generators are particularly likely to hold resources like file descriptors.

----------

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

From report at bugs.python.org  Fri Jul  3 04:10:16 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 03 Jul 2020 08:10:16 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1593763816.76.0.34797726519.issue40213@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I think the most important use case for these is closing async generators deterministically, since they don't support the async context manager protocol.

----------

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

From report at bugs.python.org  Fri Jul  3 04:39:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jul 2020 08:39:54 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1593765594.56.0.537322072391.issue41199@roundup.psfhosted.org>


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


----------
pull_requests:  -20436

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

From report at bugs.python.org  Fri Jul  3 04:40:39 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jul 2020 08:40:39 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1593765639.18.0.773300805153.issue41199@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +20437
pull_request: https://github.com/python/cpython/pull/21289

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

From report at bugs.python.org  Fri Jul  3 05:00:14 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Jul 2020 09:00:14 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593766814.82.0.015771903868.issue1635741@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 9d006977d7ff5a45d6e7d696c1713fdf2dd308b7 by Mohamed Koubaa in branch 'master':
bpo-1635741: Port sha256 module to multiphase init (PEP 489) (GH-21189)
https://github.com/python/cpython/commit/9d006977d7ff5a45d6e7d696c1713fdf2dd308b7


----------

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

From report at bugs.python.org  Fri Jul  3 05:07:40 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 03 Jul 2020 09:07:40 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593767260.27.0.985292548545.issue41165@roundup.psfhosted.org>


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

As we discussed in ML, PyEval_ReleaseLock is still used and removing may be not simple. Keep it as-is until Python 4.0.

----------

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

From report at bugs.python.org  Fri Jul  3 05:34:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 09:34:58 +0000
Subject: [issue35105] Document that CPython accepts "invalid" identifiers
In-Reply-To: <1540815891.13.0.788709270274.issue35105@psf.upfronthosting.co.za>
Message-ID: <1593768898.65.0.406398427008.issue35105@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jul  3 05:35:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 09:35:47 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593768947.46.0.334923302648.issue41194@roundup.psfhosted.org>


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


New changeset 74419f0c64959bb8392fcf3659058410423038e1 by Victor Stinner in branch 'master':
bpo-41194: Pass module state in Python-ast.c (GH-21284)
https://github.com/python/cpython/commit/74419f0c64959bb8392fcf3659058410423038e1


----------

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

From report at bugs.python.org  Fri Jul  3 06:25:40 2020
From: report at bugs.python.org (Digital India)
Date: Fri, 03 Jul 2020 10:25:40 +0000
Subject: [issue41194] Digital India
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593771940.08.0.513642295492.issue41194@roundup.psfhosted.org>


Digital India <digitalindiagovin16032020 at gmail.com> added the comment:

Digital INDIA?Common Services Centre is an online?portal?where citizens are provided access to various government services. The?CSC?e-Governance is a?portal?developed by the Ministry of Electronics and Information Technology, Government of India.?
https://www.digitalindiagov.in/
https://www.digitalindiagov.in/csc-login/

----------
nosy: +Digital India
title: SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412 -> Digital India

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

From report at bugs.python.org  Fri Jul  3 06:30:11 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 03 Jul 2020 10:30:11 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593772211.05.0.86913462144.issue41194@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
title: Digital India -> SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412

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

From report at bugs.python.org  Fri Jul  3 06:48:09 2020
From: report at bugs.python.org (Bruce Day)
Date: Fri, 03 Jul 2020 10:48:09 +0000
Subject: [issue41200] Add pickle.loads fuzz test
Message-ID: <1593773289.43.0.165410950375.issue41200@roundup.psfhosted.org>


New submission from Bruce Day <daitaomail at gmail.com>:

add pickle.loads(x) fuzz test

----------
components: Tests
messages: 372916
nosy: Bruce Day
priority: normal
pull_requests: 20438
severity: normal
status: open
title: Add pickle.loads fuzz test
type: security
versions: Python 3.10

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

From report at bugs.python.org  Fri Jul  3 06:52:33 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 03 Jul 2020 10:52:33 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593773553.98.0.0951720595884.issue41194@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
Removed message: https://bugs.python.org/msg372915

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

From report at bugs.python.org  Fri Jul  3 07:16:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 11:16:49 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593775009.08.0.35405337661.issue41194@roundup.psfhosted.org>


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


----------
pull_requests: +20439
pull_request: https://github.com/python/cpython/pull/21290

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

From report at bugs.python.org  Fri Jul  3 07:17:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 11:17:28 +0000
Subject: [issue41194] SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593775048.24.0.856315169134.issue41194@roundup.psfhosted.org>


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


----------
versions: +Python 3.10

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

From report at bugs.python.org  Fri Jul  3 07:31:44 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Fri, 03 Jul 2020 11:31:44 +0000
Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult
In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>
Message-ID: <1593775904.62.0.191366668106.issue17805@roundup.psfhosted.org>


Change by Volker Wei?mann <volker.weissmann at gmx.de>:


----------
pull_requests: +20440
pull_request: https://github.com/python/cpython/pull/21291

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

From report at bugs.python.org  Fri Jul  3 07:39:32 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 11:39:32 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593776372.32.0.398508814367.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

It is instructive that ArchLinux quietly and professionally packaged
mpdecimal-2.5.0 hours after the release:

https://www.archlinux.org/packages/?sort=&q=mpdecimal&maintainer=&flagged=


This is in stark contrast with Python-dev, where a maintainer of an *experimental*
*nightly* Ubuntu package that abuses --with-system-libmpdec claimed that "Ubuntu
builds are broken".  And a release manager who has no libmpdec expertise or authority
took the side of the "bug" reporter without much thought.


I presume that ArchLinux still follows the "shut up and hack" philosophy.

----------

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

From report at bugs.python.org  Fri Jul  3 07:46:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 11:46:38 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593776798.52.0.648481083274.issue41194@roundup.psfhosted.org>


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


----------
title: SIGSEGV in Python 3.9.0b3 in Python-ast.c:1412 -> Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

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

From report at bugs.python.org  Fri Jul  3 07:57:03 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Jul 2020 11:57:03 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593777423.9.0.0778706006424.issue40874@roundup.psfhosted.org>


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

As soon as a Python release enters beta phase, all dependencies are locked. Since Python 3.9.0-b1 supported --with-system-libmpdec with libmpdec-2.4.2, all future releases of 3.9.0 until EOL of 3.9 branch have to support 2.4.2. Since 3.9.0-b3 does not work with libmpdec-2.4.2 you have introduced a regression.

It's always possible to drop support for older versions of a dependency. A developer has to make a formal case for deprecation, provide technical arguments why an old version of a dependency cannot be support without great effort, and get written permission from the release manager. It's the release manager's discretion what they consider a regression. It's well in their power and authority to refuse and even revert a change if a release manager considers a change a regression. A developer can call upon the steering council to mediate.

Any kind of personal attacks on community members, core developers, or release manage is not acceptable way to resolve a dispute.

----------

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

From report at bugs.python.org  Fri Jul  3 08:02:03 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:02:03 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593777723.04.0.977707985776.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I was the one being attacked in this issue, while releasing a zero
fault library whose release procedures resemble those found in
avionics software.

----------

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

From report at bugs.python.org  Fri Jul  3 08:05:03 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:05:03 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593777903.0.0.5260161987.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Christian, you are also completely ignoring the original attack
of Anthony, so you are biased and there is no point continuing.

----------

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

From report at bugs.python.org  Fri Jul  3 08:08:05 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:08:05 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593778085.46.0.647294707447.issue40874@roundup.psfhosted.org>


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


----------
components: +Extension Modules
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Jul  3 08:10:13 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Jul 2020 12:10:13 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593778213.0.0.259232342731.issue40874@roundup.psfhosted.org>


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

> I was the one being attacked in this issue, while releasing a zero
fault library whose release procedures resemble those found in
avionics software.

I have reported this incident to the steering council and Code of Conduct working group. I let them decide who attacked whom.

In the mean time may I request that you follow our protocol for code review and backwards incompatible changes? There is no "Quod licet Iovi, non licet bovi" in Python (except that RM is close to the power of Zeus). Everybody has to follow the rules no matter who you are.

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

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

From report at bugs.python.org  Fri Jul  3 08:14:28 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:14:28 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593778468.09.0.862524458811.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I was accused of breaking the release, which is false. It is outside
of a release manager's authority to claim that an *experimental* and
*nightly* build that uses a flag in an unintended manner needs counts
as breakage.

----------

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

From report at bugs.python.org  Fri Jul  3 08:16:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 12:16:03 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593778563.31.0.629076440155.issue41194@roundup.psfhosted.org>


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


New changeset 91e1bc18bd467a13bceb62e16fbc435b33381c82 by Victor Stinner in branch 'master':
bpo-41194: The _ast module cannot be loaded more than once (GH-21290)
https://github.com/python/cpython/commit/91e1bc18bd467a13bceb62e16fbc435b33381c82


----------

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

From report at bugs.python.org  Fri Jul  3 08:17:38 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Fri, 03 Jul 2020 12:17:38 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593778658.36.0.923741929205.issue41194@roundup.psfhosted.org>


Change by Arcadiy Ivanov <arcadiy at ivanov.biz>:


----------
nosy:  -Digital India

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

From report at bugs.python.org  Fri Jul  3 08:17:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 12:17:41 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593778661.95.0.10894843085.issue41194@roundup.psfhosted.org>


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


----------
pull_requests: +20441
pull_request: https://github.com/python/cpython/pull/21292

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

From report at bugs.python.org  Fri Jul  3 08:19:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 12:19:14 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593778754.0.0.623475155544.issue41194@roundup.psfhosted.org>


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


----------
pull_requests: +20442
pull_request: https://github.com/python/cpython/pull/21293

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

From report at bugs.python.org  Fri Jul  3 08:24:35 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:24:35 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593779075.42.0.555506381198.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Raymond, Mark, Antoine:  If you think this should be reverted, I'll
revert it.

----------
nosy: +mark.dickinson, pitrou, rhettinger

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

From report at bugs.python.org  Fri Jul  3 08:26:22 2020
From: report at bugs.python.org (David Srebnick)
Date: Fri, 03 Jul 2020 12:26:22 +0000
Subject: [issue41201] Long integer arithmetic
Message-ID: <1593779182.53.0.05415381128.issue41201@roundup.psfhosted.org>


New submission from David Srebnick <srebby at gmail.com>:

The following program is one way of computing the sum of digits in a number.  It works properly for the first case, but fails for the second one.

def digitsum(num):
    digsum = 0
    tnum = num
    while tnum > 0:
        print("tnum = %d, digsum = %d" % (tnum,digsum))        
        digsum += (tnum % 10)
        tnum = int((tnum - (tnum % 10)) / 10)
    return digsum

print(digitsum(9999999999999999))
print(digitsum(99999999999999999))

----------
messages: 372925
nosy: David Srebnick
priority: normal
severity: normal
status: open
title: Long integer arithmetic
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Jul  3 08:26:45 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:26:45 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593779205.55.0.11642427177.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> backwards incompatible changes.

It is not a backwards incompatible change. Slamming a 3.9 into
a nightly build has never been supported.

----------

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

From report at bugs.python.org  Fri Jul  3 08:27:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 12:27:53 +0000
Subject: [issue38113] Remove statics from ast.c
In-Reply-To: <1568210711.23.0.951109613555.issue38113@roundup.psfhosted.org>
Message-ID: <1593779273.97.0.883600601224.issue38113@roundup.psfhosted.org>


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

> New changeset ac46eb4ad6662cf6d771b20d8963658b2186c48c by Eric Snow (Dino Viehland) in branch 'master':
> bpo-38113: Update the Python-ast.c generator to PEP384 (gh-15957)

This change introduced a subtle regression: bpo-41194. I modified the _ast module to use again a global state:

New changeset 91e1bc18bd467a13bceb62e16fbc435b33381c82 by Victor Stinner in branch 'master':
bpo-41194: The _ast module cannot be loaded more than once (GH-21290)
https://github.com/python/cpython/commit/91e1bc18bd467a13bceb62e16fbc435b33381c82


I also proposed PR 21293 to use again a module state, even if the implementation has some drawbacks (see the PR comments).

----------

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

From report at bugs.python.org  Fri Jul  3 08:34:59 2020
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 03 Jul 2020 12:34:59 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593779699.67.0.681397890739.issue40874@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

I'm +-0 on if that should be integrated into 3.9. Only a few people are using --with-system-libmpdec.  However the way that mpdecimal 2.4 and 2.5 are released, they are not usable for Debian or Ubuntu for the transition from 3.8 to 3.9.  For that, both 3.8 and 3.9 have to be available on the systems for the transition period, and that's just not possible without mpdecimal changing it's soname, or building one Python version with the internal libmpdec.

----------

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

From report at bugs.python.org  Fri Jul  3 08:40:48 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 03 Jul 2020 12:40:48 +0000
Subject: [issue41201] Long integer arithmetic
In-Reply-To: <1593779182.53.0.05415381128.issue41201@roundup.psfhosted.org>
Message-ID: <1593780048.39.0.875094434551.issue41201@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

This is because you used the floating point division operator `/` instead of the integer division `//`:


def digitsum(num):
    digsum = 0
    tnum = num
    while tnum > 0:
        print("tnum = %d, digsum = %d" % (tnum,digsum))        
        digsum += (tnum % 10)
        tnum = int((tnum - (tnum % 10)) // 10)
    return digsum

gives the result you expect.


Please ask for help on StackOverflow or the python-help mailing list first as this bug tracker is for reporting bugs in the Python interpreter itself and not for general help with Python programming.

The various numeric operator are documented at https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Fri Jul  3 08:42:30 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Jul 2020 12:42:30 +0000
Subject: [issue41201] Long integer arithmetic
In-Reply-To: <1593779182.53.0.05415381128.issue41201@roundup.psfhosted.org>
Message-ID: <1593780150.07.0.435507085807.issue41201@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jul  3 08:44:20 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 12:44:20 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593780260.4.0.634023809193.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Since this issue has been brought to the attention of the CoC
committee. Here is how *I* report issues:

   https://bugs.python.org/issue40223#msg372578
   https://bugs.python.org/issue40223#msg372637
   https://github.com/google/sanitizers/issues/1257


Note that I do not go straight into accusing people, especially
in uncertain cases. I never have any problems with my bug reports.

----------

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

From report at bugs.python.org  Fri Jul  3 09:06:51 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 13:06:51 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593781611.2.0.460709503522.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Matthias, to tell the truth, I was never sure about the soname.
I read this:

   https://www.debian.org/doc/debian-policy/ch-sharedlibs.html


"""
The SONAME and binary package name need not, and indeed normally should not, change if new interfaces are added but none are removed or changed, since this will not break binaries linked against the old shared library. Correct versioning of dependencies on the newer shared library by binaries that use the new interfaces is handled via the symbols or shlibs system (see Dependencies between the library and other packages).
"""

I took the interface to mean ABI, which did not change.  Also this:


"""Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the SONAME of the library and the corresponding name for the binary package containing the runtime shared library should change. Normally, this means the SONAME should change any time an interface is removed from the shared library or the signature of an interface (the number of parameters or the types of parameters that it takes, for example) is changed. This practice is vital to allowing clean upgrades from older versions of the package and clean transitions between the old ABI and new ABI without having to upgrade every affected package simultaneously.
"""


So I left the soname at 2.

----------

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

From report at bugs.python.org  Fri Jul  3 09:19:36 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 13:19:36 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593782376.69.0.249854624552.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> In the mean time may I request that you follow our protocol for code review.

Ah, who reviews libffi?  It is just updated.  Not counting the thousands of other cases people commit unreviewed, like in changing the C-API.

And no, Christian, that isn't "whataboutism", that is comparative analysis.

----------

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

From report at bugs.python.org  Fri Jul  3 10:00:22 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 03 Jul 2020 14:00:22 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1593784822.36.0.642151902991.issue38731@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

The regression is tracked here: https://bugs.python.org/issue40456

And a PR is under review here: https://github.com/python/cpython/pull/17134

Also, this issue is a duplicate to this: https://bugs.python.org/issue40456

One of these should be closed.

----------

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

From report at bugs.python.org  Fri Jul  3 10:11:00 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Jul 2020 14:11:00 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593785460.53.0.331666204467.issue1635741@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +20443
pull_request: https://github.com/python/cpython/pull/21294

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

From report at bugs.python.org  Fri Jul  3 10:26:06 2020
From: report at bugs.python.org (tomaszdrozdz)
Date: Fri, 03 Jul 2020 14:26:06 +0000
Subject: [issue41202] Allo to provide custom exception handler to asyncio.run()
Message-ID: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>


New submission from tomaszdrozdz <tomasz.drozdz.1 at protonmail.com>:

I wish we had:  

asyncio.run(coro, *, debug=False, excepton_handler=None)

so we could provide custome exception handler function for the loop.

----------
components: asyncio
messages: 372934
nosy: asvetlov, tomaszdrozdz, yselivanov
priority: normal
severity: normal
status: open
title: Allo to provide custom exception handler to asyncio.run()
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Jul  3 10:31:35 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 14:31:35 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593786695.78.0.711521628837.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> both 3.8 and 3.9 have to be available on the systems for the transition period.

If sonames can be incremented for libraries even if they are ABI compatible, how about using up as many as you need for the Debian
package?  Next time when I release mpdecimal, I'll ask you about
the highest version that's in use at Debian and increment it by
one.

----------

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

From report at bugs.python.org  Fri Jul  3 10:52:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 14:52:12 +0000
Subject: [issue41196] APPDATA directory is different in store installed python
In-Reply-To: <1593713283.65.0.795471519657.issue41196@roundup.psfhosted.org>
Message-ID: <1593787932.57.0.800412649572.issue41196@roundup.psfhosted.org>


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

> A crude workaround is to script PowerShell or CMD in a child process.

I mean, that's not a *terrible* workaround:

>>> import os
>>> p1 = os.path.expandvars("%APPDATA%\\test.txt")
>>> p1
'C:\\Users\\steve\\AppData\\Roaming\\test.txt'
>>> open(p1, "w").close()
>>> os.system(f'copy "{os.path.realpath(p1)}" "{p1}"')
        1 file(s) copied.
0
>>>

But yeah, definitely crude :)

----------

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

From report at bugs.python.org  Fri Jul  3 10:57:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 14:57:27 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593788247.82.0.595172559321.issue41194@roundup.psfhosted.org>


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


New changeset f8599279b6ac8c44538b608fd08c13ccf674f497 by Victor Stinner in branch '3.9':
[3.9] bpo-41194: The _ast module cannot be loaded more than once (GH-21290) (GH-21292)
https://github.com/python/cpython/commit/f8599279b6ac8c44538b608fd08c13ccf674f497


----------

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

From report at bugs.python.org  Fri Jul  3 10:59:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 14:59:20 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593788360.94.0.847978524943.issue1635741@roundup.psfhosted.org>


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


New changeset 3549ca313a6103a3adb281ef3a849298b7d7f72c by Victor Stinner in branch 'master':
bpo-1635741: Fix unicode_dealloc() for mortal interned string (GH-21270)
https://github.com/python/cpython/commit/3549ca313a6103a3adb281ef3a849298b7d7f72c


----------

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

From report at bugs.python.org  Fri Jul  3 11:03:32 2020
From: report at bugs.python.org (tomaszdrozdz)
Date: Fri, 03 Jul 2020 15:03:32 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1593788612.46.0.731457378112.issue41202@roundup.psfhosted.org>


Change by tomaszdrozdz <tomasz.drozdz.1 at protonmail.com>:


----------
title: Allo to provide custom exception handler to asyncio.run() -> Allow to provide custom exception handler to asyncio.run()

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

From report at bugs.python.org  Fri Jul  3 11:04:26 2020
From: report at bugs.python.org (tomaszdrozdz)
Date: Fri, 03 Jul 2020 15:04:26 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1593788666.22.0.908014121986.issue41202@roundup.psfhosted.org>


Change by tomaszdrozdz <tomasz.drozdz.1 at protonmail.com>:


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

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

From report at bugs.python.org  Fri Jul  3 12:08:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 16:08:24 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593792504.33.0.772110171957.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower

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

From report at bugs.python.org  Fri Jul  3 12:10:46 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Fri, 03 Jul 2020 16:10:46 +0000
Subject: [issue37322] test_ssl: test_pha_required_nocert() emits a
 ResourceWarning
In-Reply-To: <1560803734.85.0.206698450732.issue37322@roundup.psfhosted.org>
Message-ID: <1593792646.11.0.477701847411.issue37322@roundup.psfhosted.org>


Matthew Hughes <matthewhughes934 at gmail.com> added the comment:

I noticed this test was still emitting a "ResourceWarning":
----------------------------------------------------------------------
$ ./python -m test test_ssl -m TestPostHandshakeAuth 
0:00:00 load avg: 0.74 Run tests sequentially
0:00:00 load avg: 0.74 [1/1] test_ssl
/home/mjh/src/cpython/Lib/test/support/threading_helper.py:209: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 33451), raddr=('127.0.0.1', 34038)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback

== Tests result: SUCCESS ==

1 test OK.

Total duration: 1.1 sec
Tests result: SUCCESS
----------------------------------------------------------------------
and thought I would try silencing it by ensuring the SSL connection handled by the separate thread was closed before exiting. My attempt involved checking the thread's exception and acting accordingly, but I ran into a race condition which (solely as a proof of concept) I resolved by adding a sleep() call (see patch).

While I continue to search for a proper resolution I was wondering what approach someone with more insight might suggest.

----------
nosy: +mhughes
Added file: https://bugs.python.org/file49294/naive_proof_of_concept.patch

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

From report at bugs.python.org  Fri Jul  3 12:17:28 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Fri, 03 Jul 2020 16:17:28 +0000
Subject: [issue37322] test_ssl: test_pha_required_nocert() emits a
 ResourceWarning
In-Reply-To: <1560803734.85.0.206698450732.issue37322@roundup.psfhosted.org>
Message-ID: <1593793048.55.0.326079791329.issue37322@roundup.psfhosted.org>


Matthew Hughes <matthewhughes934 at gmail.com> added the comment:

Whoops, I realise the patch I shared contained a combination of two (independent) approaches I tried:

1. Add sleep and perform cleanup
2. Naively patch catch_threading_exception to accept a cleanup routine to be run upon exiting but before removing the thread.

----------

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

From report at bugs.python.org  Fri Jul  3 12:23:27 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Jul 2020 16:23:27 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593793407.08.0.721002665363.issue41198@roundup.psfhosted.org>


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

One note: in the original post, not only are the values being tested coming from NumPy's arange, but round(x[i],1) is testing *NumPy's* rounding functionality, not Python's. x[i] has type np.float64, and while np.float64 does inherit from Python's float, it also overrides float.__round__ with its own implementation (that essentially amounts to scale-by-power-of-ten, round-to-nearest-int, unscale, just like Python used to do in the bad old days). So errors from arange plus NumPy's non-correctly-rounded round means that all bets are off on what happens for values that _look_ as though they're ties when shown in decimal, but aren't actually ties thanks to the what-you-see-is-not-what-you-get nature of binary floating-point.

On arange in particular, I've never looked closely into the implementation; it's never noticeably not been "close enough" (i.e., accurate to within a few ulps either way), and I've never needed it or expected it to be perfectly correctly rounded. Now that it's been brought up, I'll take a look. (But that shouldn't keep this issue open, since that's a pure NumPy issue.)

Honestly, given the usual floating-point imprecision issues, I'm surprised that the balance is coming out as evenly as it is in Tim's and Steven's experiments. I can see why it might work for a single binade, but I'm at a loss to explain why you'd expect a perfect balance across several binades. 

For example: if you're looking at values of the form 0.xx5 in the binade [0.5, 1.0], and rounding those to two decimal places, you'd expect perfect parity, because if you pair the values from [0.5, 0.75] with the reverse of the values from [0.75, 1.0], in each pair exactly one of the two values will round up, and one down (the paired values always add up to *exactly* 1.5, with no rounding, so the errors from the decimal-to-binary rounding will always go in opposite directions). For example 0.505 rounds up, and dually 0.995 rounds down. (But whether the pair gives (up, down) or (down, up) will depend on exactly which way the rounding went when determining the nearest binary64 float, so will be essentially unpredictable.)

    >>> test_values = [x/1000 for x in range(505, 1000, 10)]
    >>> len(test_values)  # total count of values
    50
    >>> sum(round(val, 2) > val for val in test_values)  # number rounding up
    25

But then you need to make a similar argument for the next binade down: [0.25, 0.5] (which doesn't work at all in this case, because that binade contains an odd number of values).

Nevertheless, this *does* seem to work, and I haven't yet found a good explanation why. Any offers?

    >>> k = 8
    >>> test_values = [x/10**(k+1) for x in range(5, 10**(k+1), 10)]
    >>> sum(round(val, k) > val for val in test_values)
    50000000

BTW, yes, I think this issue can be closed.

----------

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

From report at bugs.python.org  Fri Jul  3 12:36:54 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Jul 2020 16:36:54 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593794214.84.0.95455816306.issue1635741@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset c0b214bc08f0da89e5b2e4b8cc9f07783833d6b8 by Dong-hee Na in branch 'master':
bpo-1635741: Port faulthandler module to multiphase initialization (GH-21294)
https://github.com/python/cpython/commit/c0b214bc08f0da89e5b2e4b8cc9f07783833d6b8


----------

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

From report at bugs.python.org  Fri Jul  3 12:43:57 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 03 Jul 2020 16:43:57 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593794637.76.0.581766754181.issue40874@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

> And a release manager who has no libmpdec expertise or authority took the side of the "bug" reporter without much thought.

What is this elusive "authority" you keep bringing up?

> Note that I do not go straight into accusing people, especially in uncertain cases.

Neither did Anthony. He observed breakage in his builds and reported it. He noted that the change happened during the beta freeze which is documented to only allow bug fixes:

https://devguide.python.org/devcycle/#beta

Anthony's only fault here was depending on the system libmpdec which you claim is invalid use. As he explained, he did this to mirror behavior of the official Python packages. And it worked for the first three betas. His surprise breakage report wasn't unreasonable, let alone "petulant". Compare with your own responses which to many of us read unnecessarily defensive.

Nobody is challenging your competence. The problem is entirely with the timing and making non-bugfix changes during the beta phase. Bringing up credentials, track records, or listing professional networks doesn't change that.

Finally, while Raymond and Antoine are welcome to voice their opinions on the matter, your change is landing in 3.9.0b4 which I'm about to announce. So we won't be reverting it. In the future let's make sure we stick to the release calendar to avoid similar heat. If we need to bend a rule or two, that's okay, it happens. Making a fellow core developer stamp your change in such case will increase visibility, and is a good practice regardless, required for example in avionics software.

----------

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

From report at bugs.python.org  Fri Jul  3 12:51:00 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 16:51:00 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593795060.53.0.106465208982.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

?ukasz, which one is nicer?

> reverting this patch passes all the tests, what's the motivation and why were there no code reviews for this?

or:

> Yeah, I already felt a bit guilty about adding you -- it could be a compiler bug or an actual overflow.  My bet is also that the reordering exposes an existing overflow.  The reordering itself certainly looks correct to me.



I'm always astonished that some of the CoC proponents (and reporters)
have little idea about actual politeness, a fact which is a main source
of friction.


Hint: I'd prefer actual politeness.

----------

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

From report at bugs.python.org  Fri Jul  3 12:52:07 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 16:52:07 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593795127.24.0.285728415685.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Finally, about the Debian issue, of course you could also link 3.8
against the static lib.

----------

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

From report at bugs.python.org  Fri Jul  3 13:14:26 2020
From: report at bugs.python.org (Ashley Whetter)
Date: Fri, 03 Jul 2020 17:14:26 +0000
Subject: [issue41110] 2to3 reports some files as both not changing and having
 been modified
In-Reply-To: <1593060415.61.0.690471186098.issue41110@roundup.psfhosted.org>
Message-ID: <1593796466.28.0.0826495490663.issue41110@roundup.psfhosted.org>


Change by Ashley Whetter <ashley at awhetter.co.uk>:


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

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

From report at bugs.python.org  Fri Jul  3 13:27:51 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 17:27:51 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593797271.3.0.678919388897.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> Finally, while Raymond and Antoine are welcome to voice their opinions on the matter, your change is landing in 3.9.0b4 which I'm about to announce. So we won't be reverting it. In the future let's make sure we stick to the release calendar to avoid similar heat. If we need to bend a rule or two, that's okay, it happens. Making a fellow core developer stamp your change in such case will increase visibility, and is a good practice regardless, required for example in avionics software.

I've added Antoine, Mark and Raymond because they know the history of
libmpdec, unlike people who came later.

Like for libffi, it is not feasible to get review, because there is
no time.  This would effectively mean that nothing ever changes.

The alternative is to trust that the zero fault situation continues.

Or download *one* of the gigantic test suites, which I have laboriously
updated for this release:

http://www.bytereef.org/software/mpdecimal/releases/mpdecimal-testit-2.5.0.tar.gz

The second one isn't even published.


So again, just clamoring for review (which often is just rubber
stamping) leads to nothing but scoring a few cheap points.

----------

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

From report at bugs.python.org  Fri Jul  3 13:43:50 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Jul 2020 17:43:50 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593798230.47.0.500010061251.issue40874@roundup.psfhosted.org>


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

Are you saying that you are not follow advises and guidelines of the developer guide?

----------

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

From report at bugs.python.org  Fri Jul  3 13:46:22 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jul 2020 17:46:22 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593798382.87.0.678137456332.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

How witty!

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

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

From report at bugs.python.org  Fri Jul  3 13:48:30 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 17:48:30 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593798510.42.0.956232297804.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20446
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21297

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

From report at bugs.python.org  Fri Jul  3 14:01:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 18:01:53 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593799313.54.0.691351410256.issue41194@roundup.psfhosted.org>


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


New changeset b1cc6ba73a51d5cc3aeb113b5e7378fb50a0e20a by Victor Stinner in branch 'master':
bpo-41194: Convert _ast extension to PEP 489 (GH-21293)
https://github.com/python/cpython/commit/b1cc6ba73a51d5cc3aeb113b5e7378fb50a0e20a


----------

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

From report at bugs.python.org  Fri Jul  3 14:04:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 18:04:07 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1593799447.3.0.223228085346.issue41194@roundup.psfhosted.org>


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

I cannot reproduce msg372859 crash anymore. I tested 3.9 and master branches. I close the issue.

Thanks Arcadiy Ivanov for testing beta releases ;-)

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

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

From report at bugs.python.org  Fri Jul  3 14:23:06 2020
From: report at bugs.python.org (Patrick Reader)
Date: Fri, 03 Jul 2020 18:23:06 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
Message-ID: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>


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

Since 10.12 (Sierra, released in 2016), macOS is no longer called OS X. References to macOS in the documentation should be updated to reflect this. This is now especially important because macOS 11 (Big Sur) is now in preview, and the X meaning 10 in roman numerals is now completely incorrect (not just the wrong name).

----------
assignee: docs at python
components: Documentation
messages: 372951
nosy: docs at python, pxeger
priority: normal
severity: normal
status: open
title: Replace references to OS X in documentation with macOS
type: behavior

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

From report at bugs.python.org  Fri Jul  3 14:53:01 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Jul 2020 18:53:01 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593802381.25.0.545635498531.issue41198@roundup.psfhosted.org>


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

Just for fun, I posted a Stack Overflow question: https://stackoverflow.com/q/62721186/270986

Let's close this here.

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

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

From report at bugs.python.org  Fri Jul  3 15:14:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Jul 2020 19:14:03 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1593803643.33.0.723863825664.issue41199@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests:  -20437

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

From report at bugs.python.org  Fri Jul  3 15:33:32 2020
From: report at bugs.python.org (Hubert Pineault)
Date: Fri, 03 Jul 2020 19:33:32 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1593804812.25.0.634890462532.issue38731@roundup.psfhosted.org>


Hubert Pineault <hpineault at riseup.net> added the comment:

Thanks Joannah, I confirm this is a duplicate of https://bugs.python.org/issue40456

The issue is better tracked in 40456, so you can close here.

----------

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

From report at bugs.python.org  Fri Jul  3 15:40:55 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 03 Jul 2020 19:40:55 +0000
Subject: [issue41110] 2to3 reports some files as both not changing and having
 been modified
In-Reply-To: <1593060415.61.0.690471186098.issue41110@roundup.psfhosted.org>
Message-ID: <1593805255.48.0.281982917294.issue41110@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +benjamin.peterson
type:  -> behavior
versions:  -Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Jul  3 15:54:50 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 19:54:50 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593806090.4.0.554611228355.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20447
pull_request: https://github.com/python/cpython/pull/21298

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

From report at bugs.python.org  Fri Jul  3 15:55:44 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Fri, 03 Jul 2020 19:55:44 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593549875.63.0.81357373837.issue41176@roundup.psfhosted.org>
Message-ID: <1593806144.13.0.456119022914.issue41176@roundup.psfhosted.org>


Change by Richard Sheridan <richard.sheridan at gmail.com>:


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

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

From report at bugs.python.org  Fri Jul  3 16:42:11 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 03 Jul 2020 20:42:11 +0000
Subject: [issue41198] Round built-in function not shows zeros acording
 significant figures and calculates different numbers of odd and even
In-Reply-To: <1593720386.55.0.143813033698.issue41198@roundup.psfhosted.org>
Message-ID: <1593808931.8.0.698185757223.issue41198@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Thanks, Mark! I didn't even know __round__ had become a dunder method.

For the rest, I'll follow StackOverflow - I don't have an instant answer, and the instant answers I _had_ didn't survive second thoughts ;-)

----------

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

From report at bugs.python.org  Fri Jul  3 16:50:57 2020
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Fri, 03 Jul 2020 20:50:57 +0000
Subject: [issue33327] Add a method to move messages to IMAPlib
In-Reply-To: <1524337803.72.0.682650639539.issue33327@psf.upfronthosting.co.za>
Message-ID: <1593809457.0.0.61002291088.issue33327@roundup.psfhosted.org>


Hans-Peter Jansen <hpj at urpla.net> added the comment:

If I'm not mistaken, this is applied to the openSUSE TW version of Python. 
For some reason, this seems to not play well with <instance>.uid('move',...)
on a cyrus imap server (v2.4.19). Is that to be expected?

```
2020-07-03 18:04:05  INFO: [imap_reorg] move b'10399' from 2017-01-01 06:30:35+02:00 to INBOX.2017
Traceback (most recent call last):
  File "./imap_reorg.py", line 431, in <module>
    sys.exit(main())
  File "./imap_reorg.py", line 425, in main
    return process()
  File "./imap_reorg.py", line 133, in trace_and_call
    result = func(*args, **kwargs)
  File "./imap_reorg.py", line 358, in process
    ret |= reorg.run_expr(expr)
  File "./imap_reorg.py", line 345, in run_expr
    return method(*args)
  File "./imap_reorg.py", line 328, in yearly
    ret = self.imap.uid('move', uid, dest)
  File "/usr/lib64/python3.8/imaplib.py", line 881, in uid
    typ, dat = self._simple_command(name, command, *args)
  File "/usr/lib64/python3.8/imaplib.py", line 1205, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python3.8/imaplib.py", line 1030, in _command_complete
    raise self.error('%s command error: %s %s' % (name, typ, data))
imaplib.error: UID command error: BAD [b'Unrecognized UID subcommand']
```

----------
nosy: +frispete

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

From report at bugs.python.org  Fri Jul  3 16:55:04 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 20:55:04 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593809704.62.0.707663397009.issue41180@roundup.psfhosted.org>


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

Ah, you're right. Thanks for double checking me :)

I'll merge the PR and do the backports. Thanks!

----------

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

From report at bugs.python.org  Fri Jul  3 16:56:37 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 20:56:37 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593809797.13.0.0355427037206.issue41180@roundup.psfhosted.org>


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


New changeset d160e0f8e283d0a8737644588b38e8c6a07c134f by tkmikan in branch 'master':
bpo-41180: Audit code.__new__ when unmarshalling (GH-21271)
https://github.com/python/cpython/commit/d160e0f8e283d0a8737644588b38e8c6a07c134f


----------

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

From report at bugs.python.org  Fri Jul  3 16:56:49 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 20:56:49 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593809809.67.0.639983404659.issue41180@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20449
pull_request: https://github.com/python/cpython/pull/21300

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

From report at bugs.python.org  Fri Jul  3 16:57:13 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 20:57:13 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593809833.03.0.261117439229.issue41180@roundup.psfhosted.org>


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


----------
pull_requests: +20450
pull_request: https://github.com/python/cpython/pull/21301

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

From report at bugs.python.org  Fri Jul  3 17:06:52 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 21:06:52 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593810412.35.0.26141726216.issue41162@roundup.psfhosted.org>


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


New changeset daa0fe03a517d335d48e65ace8e5da636e265a8f by Konge in branch 'master':
bpo-41162: Clear audit hooks later during finalization (GH-21222)
https://github.com/python/cpython/commit/daa0fe03a517d335d48e65ace8e5da636e265a8f


----------

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

From report at bugs.python.org  Fri Jul  3 17:13:36 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 21:13:36 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593810816.31.0.754457474312.issue41180@roundup.psfhosted.org>


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


New changeset c1d916595eb6979d4d87cc3e5216e26b3c6fac25 by Miss Islington (bot) in branch '3.8':
bpo-41180: Audit code.__new__ when unmarshalling (GH-21271)
https://github.com/python/cpython/commit/c1d916595eb6979d4d87cc3e5216e26b3c6fac25


----------

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

From report at bugs.python.org  Fri Jul  3 17:15:59 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Jul 2020 21:15:59 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593810959.54.0.636966864702.issue41192@roundup.psfhosted.org>


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


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Fri Jul  3 17:16:26 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jul 2020 21:16:26 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1593810986.33.0.013954660981.issue41180@roundup.psfhosted.org>


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


New changeset 1c776541a8805576c0a4363ca28c1d29423f02f6 by Miss Islington (bot) in branch '3.9':
bpo-41180: Audit code.__new__ when unmarshalling (GH-21271)
https://github.com/python/cpython/commit/1c776541a8805576c0a4363ca28c1d29423f02f6


----------

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

From report at bugs.python.org  Fri Jul  3 17:20:40 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 21:20:40 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593811240.17.0.269842175678.issue41162@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20451
pull_request: https://github.com/python/cpython/pull/21302

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

From report at bugs.python.org  Fri Jul  3 17:24:37 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 21:24:37 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593811477.65.0.986490347394.issue29778@roundup.psfhosted.org>


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

Bumping to release blocker and adding RMs. Should definitely get this fix merged within the next week, and I don't want the next round of releases to go out without it.

----------
nosy: +lukasz.langa, ned.deily
priority: normal -> release blocker
versions:  -Python 3.5

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

From report at bugs.python.org  Fri Jul  3 17:40:06 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Jul 2020 21:40:06 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593812406.28.0.0784680807835.issue39542@roundup.psfhosted.org>


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

PyTuple_Check() got slower across the board.  This is problematic because the principal use case for PyTuple_Check() is as a guard for various fast paths.

The direct cause of the degradation is that the inlining of PyType_Check() didn't go so well ? commit 509dd90f4684e40af3105dd3e754fa4b9c1530c1. 

There are two issues.  First, we lost the fast path for an exact type match that was present in the 3.8 version of PyType_Check().  Second, functions like PyType_Check() cannot be fully inlined if they call other non-inlined functions like PyType_GetFlags().

The original unreviewed commit doesn't revert cleanly because subsequent changes were made.  Instead, I suggest:

* restore the short-cut for an exact type match, and
* convert PyType_GetFlags() to a macro or an inlined function

That would fix the performance regression while still treating type objects as opaque.

------- Incomplete inlines ----------------------------------------------
------- line 639 in object.h --------------------------------------------

static inline int
PyType_HasFeature(PyTypeObject *type, unsigned long feature) {
    return ((PyType_GetFlags(type) & feature) != 0);
}
               ^---- Non-static function cannot be inlined

#define PyType_FastSubclass(type, flag) PyType_HasFeature(type, flag)

static inline int _PyType_Check(PyObject *op) {
    return PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_TYPE_SUBCLASS);
}
#define PyType_Check(op) _PyType_Check(_PyObject_CAST(op))


------- Old Type Check Code ---------------------------------------------
------- line 646 in object.h --------------------------------------------

#define PyObject_TypeCheck(ob, tp) \
    (Py_TYPE(ob) == (tp) || PyType_IsSubtype(Py_TYPE(ob), (tp)))
                 ^--- Fast path for exact match is now gone


------- Non-static function cannot be inlined --------------------------
------- line 2339 in typeobject.c  -------------------------------------

unsigned long
PyType_GetFlags(PyTypeObject *type)
{
    return type->tp_flags;
}

----------
nosy: +lukasz.langa, petr.viktorin, pitrou, rhettinger
priority: normal -> high
status: closed -> open

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

From report at bugs.python.org  Fri Jul  3 17:47:00 2020
From: report at bugs.python.org (Brad Larsen)
Date: Fri, 03 Jul 2020 21:47:00 +0000
Subject: [issue41204] Use of unitialized variable `fields` along error path in
 code generated from asdl_c.py
Message-ID: <1593812820.7.0.967275410849.issue41204@roundup.psfhosted.org>


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

In commit b1cc6ba73 from earlier today, an error-handling path can now read an uninitialized variable.

https://github.com/python/cpython/commit/b1cc6ba73a51d5cc3aeb113b5e7378fb50a0e20a#diff-fa7f27df4c8df1055048e78340f904c4R695-R697

In particular, asdl_c.py is used to generate C source, and when building that code with Clang 10, there is the attached warning.

Likely fix: initialize `fields` to `NULL`. Also, perhaps a CI loop that has `-Werror=sometimes-uninitialized` would help detect these.

Compiler warning:

Python/Python-ast.c:1147:9: warning: variable 'fields' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
    if (state == NULL) {
        ^~~~~~~~~~~~~
Python/Python-ast.c:1210:16: note: uninitialized use occurs here
    Py_XDECREF(fields);
               ^~~~~~
./Include/object.h:520:51: note: expanded from macro 'Py_XDECREF'
#define Py_XDECREF(op) _Py_XDECREF(_PyObject_CAST(op))
                                                  ^~
./Include/object.h:112:41: note: expanded from macro '_PyObject_CAST'
#define _PyObject_CAST(op) ((PyObject*)(op))
                                        ^~
Python/Python-ast.c:1147:5: note: remove the 'if' if its condition is always false
    if (state == NULL) {
    ^~~~~~~~~~~~~~~~~~~~
Python/Python-ast.c:1145:35: note: initialize the variable 'fields' to silence this warning
    PyObject *key, *value, *fields;
                                  ^
                                   = NULL
1 warning generated.

----------
components: Interpreter Core
messages: 372963
nosy: blarsen, vstinner
priority: normal
severity: normal
status: open
title: Use of unitialized variable `fields` along error path in code generated from asdl_c.py
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Fri Jul  3 17:58:08 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 21:58:08 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593813488.34.0.193270783805.issue41192@roundup.psfhosted.org>


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

Maybe we need to add a page for "undocumented" events? I really don't want to document the _ctypes or _winapi modules - those should remain internal-only.

Maybe we can add a section to the end of the audit_events.rst file for "other events"? The generation of that page happens in two separate passes, so it should be safe enough.

It might even be possible to just provide the events and specify "" instead of the anchor to disable the backlink completely? I don't remember whether I coded that up or not.

----------

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

From report at bugs.python.org  Fri Jul  3 17:58:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 21:58:47 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593813527.44.0.697618111398.issue41162@roundup.psfhosted.org>


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


New changeset e1d4fdc53347617bea1aff0d7112471453f65003 by Steve Dower in branch '3.9':
bpo-41162: Clear audit hooks later during finalization (GH-21222)
https://github.com/python/cpython/commit/e1d4fdc53347617bea1aff0d7112471453f65003


----------

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

From report at bugs.python.org  Fri Jul  3 18:00:12 2020
From: report at bugs.python.org (Matej Cepl)
Date: Fri, 03 Jul 2020 22:00:12 +0000
Subject: [issue33327] Add a method to move messages to IMAPlib
In-Reply-To: <1524337803.72.0.682650639539.issue33327@psf.upfronthosting.co.za>
Message-ID: <1593813612.81.0.0468948903326.issue33327@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

1. no this has not been included anywhere, just in the unfinished PR on GitHub
2. only thing which I was fighting to get into Python (and I did) was https://bugs.python.org/issue33336 but that?s another issue (without this whole discussion here would not be even possible), it is now part of the upstream Python
3. are you certain that the IMAP server in question supports MOVE command? (have you noticed all that business with CAPABILITIES and particularly the UID one?)

----------

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

From report at bugs.python.org  Fri Jul  3 18:01:05 2020
From: report at bugs.python.org (Matej Cepl)
Date: Fri, 03 Jul 2020 22:01:05 +0000
Subject: [issue33327] Add a method to move messages to IMAPlib
In-Reply-To: <1524337803.72.0.682650639539.issue33327@psf.upfronthosting.co.za>
Message-ID: <1593813664.99.0.76738686707.issue33327@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

Sorry, UIDPLUS capability.

----------

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

From report at bugs.python.org  Fri Jul  3 18:05:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:05:47 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593813947.57.0.571005729714.issue41162@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20452
pull_request: https://github.com/python/cpython/pull/21303

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

From report at bugs.python.org  Fri Jul  3 18:06:09 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:06:09 +0000
Subject: [issue21222] Mock create_autospec with name argument fails
In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za>
Message-ID: <1593813969.84.0.0664339162526.issue21222@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower
nosy_count: 3.0 -> 4.0
pull_requests: +20453
pull_request: https://github.com/python/cpython/pull/21304

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

From report at bugs.python.org  Fri Jul  3 18:06:20 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Jul 2020 22:06:20 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1593813980.35.0.519049017719.issue41199@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +newcomer friendly -patch

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

From report at bugs.python.org  Fri Jul  3 18:32:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:32:47 +0000
Subject: [issue21222] Mock create_autospec with name argument fails
In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za>
Message-ID: <1593815567.55.0.758824011777.issue21222@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests:  -20453

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

From report at bugs.python.org  Fri Jul  3 18:32:54 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:32:54 +0000
Subject: [issue21222] Mock create_autospec with name argument fails
In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za>
Message-ID: <1593815574.54.0.883145439552.issue21222@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy:  -steve.dower

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

From report at bugs.python.org  Fri Jul  3 18:33:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:33:21 +0000
Subject: [issue21222] Mock create_autospec with name argument fails
In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za>
Message-ID: <1593815601.84.0.967818092169.issue21222@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower
nosy_count: 3.0 -> 4.0
pull_requests: +20455
pull_request: https://github.com/python/cpython/pull/21304

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

From report at bugs.python.org  Fri Jul  3 18:33:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:33:21 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593815601.69.0.0408400109987.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20454
pull_request: https://github.com/python/cpython/pull/21304

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

From report at bugs.python.org  Fri Jul  3 18:33:44 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:33:44 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593815624.07.0.674732012226.issue41162@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20456
pull_request: https://github.com/python/cpython/pull/21304

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

From report at bugs.python.org  Fri Jul  3 18:34:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:34:38 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593815678.46.0.642937110544.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests:  -20454

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

From report at bugs.python.org  Fri Jul  3 18:34:53 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:34:53 +0000
Subject: [issue21222] Mock create_autospec with name argument fails
In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za>
Message-ID: <1593815693.24.0.335226371992.issue21222@roundup.psfhosted.org>


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


New changeset 941117aaa32bf8b02c739ad848ac727292f75b05 by Steve Dower in branch '3.9':
bpo-21222: Fix improperly merged change so that final hooks are called before types are cleared (GH-21304)
https://github.com/python/cpython/commit/941117aaa32bf8b02c739ad848ac727292f75b05


----------

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

From report at bugs.python.org  Fri Jul  3 18:44:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 22:44:03 +0000
Subject: [issue41173] Windows ARM buildbots cannot upload results
In-Reply-To: <1593532689.42.0.224097599218.issue41173@roundup.psfhosted.org>
Message-ID: <1593816243.62.0.351355157951.issue41173@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Fri Jul  3 18:51:25 2020
From: report at bugs.python.org (JD-Veiga)
Date: Fri, 03 Jul 2020 22:51:25 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
Message-ID: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>


New submission from JD-Veiga <jdveiga at gmail.com>:

Hi,

I would like to propose a minor addition to `decimal` package documentation page (https://docs.python.org/3/library/decimal.html). I think that we should add a paragraph in `context.power(x, y, modulo=None)` stating that `Decimal(0) ** Decimal(0)` returns `Decimal('NaN')` instead of `1` --as `0 ** 0` does-- or `1.0` --in case of `0.0 ** 0.0`.

Indeed, `0 ** 0` is `NaN` is mentioned as example of operations raising `InvalidOperation` exceptions.

However, I think that this is not enough to indicate the different behaviour of decimal versus int and float numbers.

Moreover, in the case of `%` and `//` operators, there are clear remarks on these differences (See: ?There are some small differences between arithmetic on Decimal objects and arithmetic on integers and floats [...]? in the page).

Thank you and sorry for the inconvenience.

----------
assignee: docs at python
components: Documentation
messages: 372969
nosy: JD-Veiga, docs at python
priority: normal
severity: normal
status: open
title: Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jul  3 19:04:35 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jul 2020 23:04:35 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1593817475.84.0.110676572466.issue41162@roundup.psfhosted.org>


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


New changeset b9e288cc1bfd583e887f784e38d9c511b43c0c3a by Steve Dower in branch '3.8':
bpo-41162: Clear audit hooks later during finalization (GH-21222)
https://github.com/python/cpython/commit/b9e288cc1bfd583e887f784e38d9c511b43c0c3a


----------

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

From report at bugs.python.org  Fri Jul  3 19:04:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 23:04:47 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1593817487.65.0.629979480312.issue29778@roundup.psfhosted.org>


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


----------
pull_requests: +20458
pull_request: https://github.com/python/cpython/pull/21306

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

From report at bugs.python.org  Fri Jul  3 19:10:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jul 2020 23:10:05 +0000
Subject: [issue41204] Use of unitialized variable `fields` along error path in
 code generated from asdl_c.py
In-Reply-To: <1593812820.7.0.967275410849.issue41204@roundup.psfhosted.org>
Message-ID: <1593817805.05.0.844317924171.issue41204@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jul  3 19:14:58 2020
From: report at bugs.python.org (David Bremner)
Date: Fri, 03 Jul 2020 23:14:58 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
Message-ID: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>


New submission from David Bremner <bremner at unb.ca>:

Works in 3.8.3, but not in 3.8.4rc1

from email.message import EmailMessage
msg = EmailMessage()
msg.set_content("")

Apparently now at least one newline is required.

----------
components: email
messages: 372971
nosy: barry, bremner, r.david.murray
priority: normal
severity: normal
status: open
title: behaviour change with EmailMessage.set_content
versions: Python 3.8

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

From report at bugs.python.org  Fri Jul  3 20:47:05 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jul 2020 00:47:05 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593823625.43.0.953831022216.issue41192@roundup.psfhosted.org>


Change by Saiyang Gou <gousaiyang223 at gmail.com>:


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

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

From report at bugs.python.org  Fri Jul  3 20:51:04 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jul 2020 00:51:04 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593823864.52.0.875328120542.issue41192@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

I've created PR 21308 for this. BTW, is issue 39567 (`os.walk`, `os.fwalk`, `pathlib.Path.glob` and `pathlib.Path.rglob`) intentionally not backported to 3.8?

----------

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

From report at bugs.python.org  Fri Jul  3 21:07:47 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 04 Jul 2020 01:07:47 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593824867.1.0.4179494391.issue41165@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +20461
pull_request: https://github.com/python/cpython/pull/21309

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

From report at bugs.python.org  Fri Jul  3 21:26:02 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 04 Jul 2020 01:26:02 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1593825962.86.0.235673132326.issue41207@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
versions: +Python 3.10

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

From report at bugs.python.org  Fri Jul  3 21:25:52 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 04 Jul 2020 01:25:52 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
Message-ID: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In [pypa/setuptools#2228](https://github.com/pypa/setuptools/issues/2228), by adopting the distutils codebase from a late release of CPython, Setuptools stumbled onto an API-breaking change in distutils rooted at issue39763.

Details are in the Setuptools investigation, but to summarize:

- distutils.ccompiler.CCompiler.compile declares "raises CompileError on failure" and calls `self._compile`, implemented by subclasses.
- In at least `distutils.unixcompiler.UnixCCompiler._compile`, `distutils.spawn.spawn` is called (through CCompiler.spawn).
- Since GH-18743, `distutils.spawn.spawn` calls `subprocess.Popen` which raises FileNotFoundError when the target executable doesn't exist.
- Programs trapping CompileError but not FileNotFoundError will crash where once they had error handling.

Setuptools discovered this behavior in the 48.0 release when it incorporated these distutils changes into a vendored release of Setuptools, but the failures exhibited will apply to all builds (including pyyaml) on Python 3.9.

----------
assignee: lukasz.langa
components: Distutils
keywords: 3.9regression
messages: 372973
nosy: dstufft, eric.araujo, jaraco, lukasz.langa
priority: release blocker
severity: normal
status: open
title: distutils.command.build_ext raises FileNotFoundError
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul  3 21:26:37 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 04 Jul 2020 01:26:37 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1593825997.77.0.58149690277.issue39763@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've flagged issue41207 as a regression stemming from this effort.

----------
nosy: +jaraco

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

From report at bugs.python.org  Fri Jul  3 22:02:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jul 2020 02:02:43 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
In-Reply-To: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>
Message-ID: <1593828163.55.0.0178380300381.issue41203@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Fri Jul  3 22:03:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jul 2020 02:03:36 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1593828216.94.0.70576800303.issue41205@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah

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

From report at bugs.python.org  Fri Jul  3 22:04:55 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jul 2020 02:04:55 +0000
Subject: [issue41192] Some audit events are undocumented
In-Reply-To: <1593671252.05.0.986281783812.issue41192@roundup.psfhosted.org>
Message-ID: <1593828295.37.0.80852246333.issue41192@roundup.psfhosted.org>


Change by Saiyang Gou <gousaiyang223 at gmail.com>:


----------
pull_requests: +20462
pull_request: https://github.com/python/cpython/pull/21310

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

From report at bugs.python.org  Fri Jul  3 23:45:02 2020
From: report at bugs.python.org (Tim Peters)
Date: Sat, 04 Jul 2020 03:45:02 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1593834302.7.0.280226428028.issue41205@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Huh! I thought everyone in Standards World gave up by now, and agreed 0**0 should be 1.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Fri Jul  3 23:46:53 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 04 Jul 2020 03:46:53 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593834413.58.0.751022130269.issue33864@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 5.0 -> 6.0
pull_requests: +20463
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21311

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

From report at bugs.python.org  Fri Jul  3 23:58:28 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Jul 2020 03:58:28 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593835108.49.0.575976181363.issue33864@roundup.psfhosted.org>


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


New changeset b40e434386cd94a367d4a256e3364771140160e7 by Zackery Spytz in branch 'master':
bpo-33864: Clarify the docs for typing.ByteString (GH-21311)
https://github.com/python/cpython/commit/b40e434386cd94a367d4a256e3364771140160e7


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

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

From report at bugs.python.org  Fri Jul  3 23:58:47 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Jul 2020 03:58:47 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593835127.71.0.511403692545.issue33864@roundup.psfhosted.org>


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


----------
pull_requests: +20464
pull_request: https://github.com/python/cpython/pull/21312

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

From report at bugs.python.org  Fri Jul  3 23:58:54 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Jul 2020 03:58:54 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593835134.25.0.994143844233.issue33864@roundup.psfhosted.org>


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


----------
pull_requests: +20465
pull_request: https://github.com/python/cpython/pull/21313

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

From report at bugs.python.org  Sat Jul  4 00:05:45 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Jul 2020 04:05:45 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593835545.02.0.521543652991.issue33864@roundup.psfhosted.org>


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


New changeset 1cbcf9833f26588a16b5b69d202df727dbd09968 by Miss Islington (bot) in branch '3.9':
bpo-33864: Clarify the docs for typing.ByteString (GH-21311)
https://github.com/python/cpython/commit/1cbcf9833f26588a16b5b69d202df727dbd09968


----------

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

From report at bugs.python.org  Sat Jul  4 00:06:10 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Jul 2020 04:06:10 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593835570.92.0.0758320593318.issue33864@roundup.psfhosted.org>


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


New changeset 6857ebefc048e316f948091946d337b5ada807a4 by Miss Islington (bot) in branch '3.8':
bpo-33864: Clarify the docs for typing.ByteString (GH-21311)
https://github.com/python/cpython/commit/6857ebefc048e316f948091946d337b5ada807a4


----------

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

From report at bugs.python.org  Sat Jul  4 00:23:04 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 04 Jul 2020 04:23:04 +0000
Subject: [issue33864] collections.abc.ByteString does not register memoryview
In-Reply-To: <1529012616.87.0.947875510639.issue33864@psf.upfronthosting.co.za>
Message-ID: <1593836584.21.0.504304131278.issue33864@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Sat Jul  4 00:47:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jul 2020 04:47:24 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1593838044.23.0.614587473002.issue41206@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is caused due to c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5 introduced as part of bpo-40597 which is reported back in the issue with https://bugs.python.org/msg370395

----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Jul  4 02:49:45 2020
From: report at bugs.python.org (JD-Veiga)
Date: Sat, 04 Jul 2020 06:49:45 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1593845385.21.0.423862394833.issue41205@roundup.psfhosted.org>


JD-Veiga <jdveiga at gmail.com> added the comment:

Well, it is the way that it has been defined in `decimal` package and in the document that inspired this package (IBM's General Decimal Arithmetic Specification, The General Decimal Arithmetic Specification: http://speleotrove.com/decimal/decarith.html).

----------

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

From report at bugs.python.org  Sat Jul  4 02:53:32 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jul 2020 06:53:32 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
In-Reply-To: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>
Message-ID: <1593845612.97.0.978586710061.issue41203@roundup.psfhosted.org>


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

Would you submit at PR>

----------
nosy: +rhettinger
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Jul  4 03:16:30 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jul 2020 07:16:30 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1593846990.78.0.367854055737.issue41205@roundup.psfhosted.org>


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

I agree that the result is surprising and should be noted in the docs; we shouldn't expect all the decimal users to be familiar with the specification. Some of the other differences with float arithmetic *are* noted (e.g., the behaviour of `//` and `%`), but apparently not this one. We do document the behaviour of these corner cases for `math.pow`.

The part that I find really odd is that the specification says that `Decimal("inf")**Decimal(0)` is `1`. Treating one of 0**0 and inf**0 as undefined but not the other seems inconsistent to me. We'd probably want to note the behaviour of inf**0 in the docs, too. (I tried to argue with Mike Cowlishaw about this, but I lost.)

I'm not sure whether just noting this in the "power" documentation is enough: it's not clear to me that users using the ** operator would think to check the docs for the "power" method.

The other weirdly non-IEEE 754 behaviour (again, mandated by the standard) that bugs me from time to time is that the unary `-` and `+` operators will never give negative zero: Decimal("-0.0") and -Decimal("0.0") are not the same thing. That one's probably worth noting, too.

----------

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

From report at bugs.python.org  Sat Jul  4 04:41:20 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Jul 2020 08:41:20 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593852080.59.0.79786942592.issue39542@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Christian Heimes has expressed an interest (quite rudely) in unreviewed commits elsewhere.  I wonder if that applies to everyone regardless of employer.

----------
nosy: +christian.heimes, skrah

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

From report at bugs.python.org  Sat Jul  4 05:02:33 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Jul 2020 09:02:33 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593853353.17.0.512371083541.issue39542@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Ah, I see that the subject has already been answered in the negative:

https://discuss.python.org/t/make-code-review-mandatory/4174

He must have forgotten.

----------

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

From report at bugs.python.org  Sat Jul  4 05:04:58 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sat, 04 Jul 2020 09:04:58 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
In-Reply-To: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>
Message-ID: <1593853498.9.0.344542269941.issue41203@roundup.psfhosted.org>


Patrick Reader <pxeger at protonmail.com> added the comment:

I'm working on it

----------

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

From report at bugs.python.org  Sat Jul  4 05:09:06 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 04 Jul 2020 09:09:06 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1593853746.02.0.652862362426.issue40275@roundup.psfhosted.org>


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


----------
pull_requests: +20466
pull_request: https://github.com/python/cpython/pull/21314

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

From report at bugs.python.org  Sat Jul  4 05:16:03 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 04 Jul 2020 09:16:03 +0000
Subject: [issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's
 new
In-Reply-To: <1593634040.83.0.8340731803.issue41191@roundup.psfhosted.org>
Message-ID: <1593854163.47.0.559718090321.issue41191@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +petr.viktorin, vstinner

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

From report at bugs.python.org  Sat Jul  4 05:22:30 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Jul 2020 09:22:30 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1593854550.05.0.161116583081.issue41205@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Agreed, and it's even slightly worse with the ROUND_FLOOR special case:

>>> c.rounding = ROUND_FLOOR
>>> +Decimal("-0")
Decimal('-0')
>>> 

That's why there are three slightly different methods for applying the
context:

   1) context.create_decimal() ==> special case for NaN payloads.

   2) context.apply() (private method) ==> no special cases at all.

   3) Decimal.plus() ==> ROUND_FLOOR special case.

----------

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

From report at bugs.python.org  Sat Jul  4 05:40:30 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sat, 04 Jul 2020 09:40:30 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
In-Reply-To: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>
Message-ID: <1593855630.46.0.172512666623.issue41203@roundup.psfhosted.org>


Patrick Reader <pxeger at protonmail.com> added the comment:

While I'm at it, should I change "Macintosh" to "Mac"?

----------

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

From report at bugs.python.org  Sat Jul  4 06:02:13 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 04 Jul 2020 10:02:13 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1593856933.83.0.468795550063.issue40275@roundup.psfhosted.org>


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


----------
pull_requests: +20467
pull_request: https://github.com/python/cpython/pull/21315

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

From report at bugs.python.org  Sat Jul  4 06:02:36 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sat, 04 Jul 2020 10:02:36 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
In-Reply-To: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>
Message-ID: <1593856956.19.0.592647458659.issue41203@roundup.psfhosted.org>


Change by Patrick Reader <pxeger at protonmail.com>:


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

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

From report at bugs.python.org  Sat Jul  4 06:50:33 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 04 Jul 2020 10:50:33 +0000
Subject: [issue41203] Replace references to OS X in documentation with macOS
In-Reply-To: <1593800586.51.0.799645858165.issue41203@roundup.psfhosted.org>
Message-ID: <1593859833.74.0.503825476869.issue41203@roundup.psfhosted.org>


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

As I mentioned in my review on the PR I'd prefer to keep using Macintosh where it is used to denote to MacOS 9 and earlier. Both out of nostalgia and because that older OS was substantially different from the current OS.

----------

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

From report at bugs.python.org  Sat Jul  4 07:27:57 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 04 Jul 2020 11:27:57 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1593862077.2.0.753064589229.issue40275@roundup.psfhosted.org>


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


----------
pull_requests: +20470
pull_request: https://github.com/python/cpython/pull/21317

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

From report at bugs.python.org  Sat Jul  4 07:31:54 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 04 Jul 2020 11:31:54 +0000
Subject: [issue37458] ast: Different FormattedValue expressions have same
 col_offset information
In-Reply-To: <1561947041.86.0.747696740213.issue37458@roundup.psfhosted.org>
Message-ID: <1593862314.31.0.855663540589.issue37458@roundup.psfhosted.org>


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

I still see this problem with 3.10, which I thought might have fixed this.

@lys.nikolaou: any ideas on this?

----------
components: +Interpreter Core -Library (Lib)
nosy: +lys.nikolaou
versions: +Python 3.10 -Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Jul  4 07:56:29 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Sat, 04 Jul 2020 11:56:29 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
Message-ID: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>


New submission from Iman Sharafodin <iman.sharafodin at gmail.com>:

It seems that all versions of Python 3 are vulnerable to de-marshaling the attached file (Python file is included). I've tested on Python 3.10.0a0 (heads/master:b40e434, Jul  4 2020), Python 3.6.11 and Python 3.7.2. This is due to lack of proper validation at Objects/tupleobject.c:413 (heads/master:b40e434).
 
This is the result of GDB's Exploitable plugin (it's exploitable):
Description: Access violation during branch instruction
Short description: BranchAv (4/22)
Hash: e04b830dfb409a8bbf67bff96ff0df44.4d31b48b56e0c02ed51520182d91a457
Exploitability Classification: EXPLOITABLE
Explanation: The target crashed on a branch instruction, which may indicate that the control flow is tainted.
Other tags: AccessViolation (21/22)

----------
components: Interpreter Core
files: Crash.zip
messages: 372990
nosy: Iman Sharafodin
priority: normal
severity: normal
status: open
title: An exploitable segmentation fault in marshal module
type: security
versions: Python 3.10
Added file: https://bugs.python.org/file49295/Crash.zip

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

From report at bugs.python.org  Sat Jul  4 09:23:47 2020
From: report at bugs.python.org (=?utf-8?q?Josef_Havr=C3=A1nek?=)
Date: Sat, 04 Jul 2020 13:23:47 +0000
Subject: [issue41128] Signal handlers should not hang during blocked main
 thread
In-Reply-To: <1593192889.65.0.44895771655.issue41128@roundup.psfhosted.org>
Message-ID: <1593869027.88.0.514072402019.issue41128@roundup.psfhosted.org>


Change by Josef Havr?nek <jhpepa at gmail.com>:


----------
nosy:  -Josef Havr?nek

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

From report at bugs.python.org  Sat Jul  4 09:24:27 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 04 Jul 2020 13:24:27 +0000
Subject: [issue37458] ast: Different FormattedValue expressions have same
 col_offset information
In-Reply-To: <1561947041.86.0.747696740213.issue37458@roundup.psfhosted.org>
Message-ID: <1593869067.23.0.853130329616.issue37458@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

> I still see this problem with 3.10, which I thought might have fixed this.
Nope, that's still true in 3.10.

>I'm working on overhauling how these are calculated. But it's complex, and is taking a while.
In short, the FormattedValue nodes all have the exact same lineno's and col_offset's, which are also identical to those of the enclosing JoinedStr node. These values are equal to lineno and col_offset of the first STRING token and end_lineno and end_col_offset of the last STRING token (note that the grammar accepts a STRING+ node).

> any ideas on this?
Moving f-string parsing to the parser, which we've been talking about lately, would solve this. But this will probably take some time, since I currently do not have the time. It's probably going to be a good project for this coming fall.

Another alternative, in case we don't want to wait until then, would be for the handwritten f-string parser to have its own instances of a lineno and col_offset, so that they can be used when the FormattedValue nodes are created. This would probably also require some effort though, so I'm not sure we want to do it, before we really know if we're gonnna proceed with the "moving f-string parsing to PEG" project.

----------

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

From report at bugs.python.org  Sat Jul  4 09:47:09 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Jul 2020 13:47:09 +0000
Subject: [issue41195] Interface to OpenSSL's security level
In-Reply-To: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>
Message-ID: <1593870429.45.0.584577319802.issue41195@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

No strong feelings on this, but the OpenSSL runtime is not always packaged by a Linux distribution.  (macOS, Windows and Anaconda come to mind)

If one wants to retain the setter facility, one could raise a RuntimeWarning if the user *lowers* the actual security level.

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

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

From report at bugs.python.org  Sat Jul  4 10:46:18 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Jul 2020 14:46:18 +0000
Subject: [issue37458] ast: Different FormattedValue expressions have same
 col_offset information
In-Reply-To: <1561947041.86.0.747696740213.issue37458@roundup.psfhosted.org>
Message-ID: <1593873978.11.0.706204196962.issue37458@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sat Jul  4 10:55:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Jul 2020 14:55:52 +0000
Subject: [issue41204] Use of unitialized variable `fields` along error path in
 code generated from asdl_c.py
In-Reply-To: <1593812820.7.0.967275410849.issue41204@roundup.psfhosted.org>
Message-ID: <1593874552.74.0.621625619336.issue41204@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sat Jul  4 12:46:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jul 2020 16:46:18 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593881178.55.0.855271294339.issue39542@roundup.psfhosted.org>


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

Let's just focus on getting it fixed before 3.9 goes out.

----------

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

From report at bugs.python.org  Sat Jul  4 13:56:01 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 04 Jul 2020 17:56:01 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593885361.45.0.426680729986.issue39542@roundup.psfhosted.org>


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

Stefan, stop it! I feel offended and harassed by you. Do not ever talk to me in public, private, or even insinuate to reference to my person in any public conversation.

----------

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

From report at bugs.python.org  Sat Jul  4 13:56:09 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 04 Jul 2020 17:56:09 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593885369.29.0.159159797327.issue39542@roundup.psfhosted.org>


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


----------
nosy:  -christian.heimes

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

From report at bugs.python.org  Sat Jul  4 14:39:17 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Jul 2020 18:39:17 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593887957.13.0.507647400976.issue39542@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I have no opinion about this commit (I did not benchmark anything,
but I wouldn't be surprised if Victor did).

I do have the opinion that unreviewed commits occur quite frequently
and nearly every committer has made some (or a lot), including the
committers who mention them.

They are not inherently bad, so I hope we can focus on the outcome.

----------

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

From report at bugs.python.org  Sat Jul  4 17:16:16 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 04 Jul 2020 21:16:16 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1593897376.38.0.96375387171.issue41177@roundup.psfhosted.org>


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

> I think the other issue here is that the ConvertingX classes aren't documented apart from comments in the code where they are defined.

That's deliberate - they're considered an internal implementation detail.

----------

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

From report at bugs.python.org  Sat Jul  4 17:18:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Jul 2020 21:18:22 +0000
Subject: [issue41204] Use of unitialized variable `fields` along error path in
 code generated from asdl_c.py
In-Reply-To: <1593812820.7.0.967275410849.issue41204@roundup.psfhosted.org>
Message-ID: <1593897502.37.0.537828690276.issue41204@roundup.psfhosted.org>


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


New changeset 1f76453173267887ed05bb3783e862cb22365ae8 by Victor Stinner in branch 'master':
bpo-41204: Fix compiler warning in ast_type_init() (GH-21307)
https://github.com/python/cpython/commit/1f76453173267887ed05bb3783e862cb22365ae8


----------

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

From report at bugs.python.org  Sat Jul  4 17:21:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Jul 2020 21:21:07 +0000
Subject: [issue41204] Use of unitialized variable `fields` along error path in
 code generated from asdl_c.py
In-Reply-To: <1593812820.7.0.967275410849.issue41204@roundup.psfhosted.org>
Message-ID: <1593897667.61.0.712558003437.issue41204@roundup.psfhosted.org>


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

Thanks for the report, it's not fixed.

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

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

From report at bugs.python.org  Sat Jul  4 17:32:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Jul 2020 21:32:27 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1593898347.27.0.768671601393.issue41177@roundup.psfhosted.org>


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

If you are going to make them public general purpose classes you need to implement also support of slices, __reversed__(), index(), remove(), count(), sort(), copy() in ConvertingList and more methods in ConvertingTuple, and ConvertingDict.

If it is not goal then I think that no any changes are needed. If they are internal classes they needed only features which are used internally by the module code.

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

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

From report at bugs.python.org  Sat Jul  4 17:41:04 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Sat, 04 Jul 2020 21:41:04 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1593898864.0.0.705285566009.issue1635741@roundup.psfhosted.org>


Change by mohamed koubaa <koubaa.m at gmail.com>:


----------
nosy: +koubaa
nosy_count: 16.0 -> 17.0
pull_requests: +20471
pull_request: https://github.com/python/cpython/pull/21319

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

From report at bugs.python.org  Sat Jul  4 18:13:10 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jul 2020 22:13:10 +0000
Subject: [issue37363] Additional PEP578 hooks
In-Reply-To: <1561131749.05.0.996884755083.issue37363@roundup.psfhosted.org>
Message-ID: <1593900790.89.0.936571990701.issue37363@roundup.psfhosted.org>


Change by Saiyang Gou <gousaiyang223 at gmail.com>:


----------
nosy: +gousaiyang
nosy_count: 4.0 -> 5.0
pull_requests: +20472
pull_request: https://github.com/python/cpython/pull/21321

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

From report at bugs.python.org  Sat Jul  4 18:24:53 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jul 2020 22:24:53 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1593901493.75.0.129455215049.issue39184@roundup.psfhosted.org>


Change by Saiyang Gou <gousaiyang223 at gmail.com>:


----------
pull_requests: +20473
pull_request: https://github.com/python/cpython/pull/21322

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

From report at bugs.python.org  Sat Jul  4 18:27:25 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jul 2020 22:27:25 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1593901645.69.0.744927280086.issue39184@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

Since the original problem (command execution functions missing audit events) is already solved, we can close this issue now. Further discussions on additional audit hooks (e.g. for the networking modules) could go to issue 37363.

----------

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

From report at bugs.python.org  Sat Jul  4 19:01:16 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Jul 2020 23:01:16 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593903676.47.0.602865160052.issue40874@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Hmm, I'm only taking notice of this comment thread now.

(sorry, but due to spam filtering issues I only receive bpo e-mail notifications intermittently... and that's despite having tried two separate e-mail providers which otherwise give me no problems :-/)

In any case, I would have had a hard time giving a competent opinion on this issue.  But I'm a bit saddened by how heated the discussion went.  Hopefully this is all over.

----------

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

From report at bugs.python.org  Sat Jul  4 19:02:28 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 04 Jul 2020 23:02:28 +0000
Subject: [issue37458] ast: Different FormattedValue expressions have same
 col_offset information
In-Reply-To: <1561947041.86.0.747696740213.issue37458@roundup.psfhosted.org>
Message-ID: <1593903748.77.0.969210783336.issue37458@roundup.psfhosted.org>


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

I think waiting until we decide what to do with the parser makes sense. This problem has been around for a while, and while it's unfortunate I don't think it's worth heroic measures to fix.

----------

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

From report at bugs.python.org  Sat Jul  4 19:44:06 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Jul 2020 23:44:06 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593906246.1.0.151189043893.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> In any case, I would have had a hard time giving a competent opinion on this issue.

Essentially it's a really simple Linux packaging issue for the
external libmpdec.  To have the exact same behavior for the external
libmpdec as for the included libmpdec, packagers must use:

  3.8  <--> 2.4.2
  3.9  <--> 2.5.0


ArchLinux had no problems.  Debian, and by extension Ubuntu, requires
3.8 and 3.9 to be on the same system during a transitional period, as
pointed out in msg372928 (which is really the most important message
of this whole thread).  

The commit that pinned _decimal to libmpdec version 2.5.0 broke this
use case, but there are workarounds.


My stance is that it is important that libmpdec is pinned so distros
don't use a divergent version.  Since there are multiple mitigations
for Debian, I don't feel particularly guilty.


Review of the commit that pinned 2.5.0 would have led to the exact
same outcome: I would have pointed that out on GitHub.

Note that with the Debian scheme there is never a good time to
update libmpdec, regardless of the release cycle.

----------

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

From report at bugs.python.org  Sat Jul  4 19:57:52 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 04 Jul 2020 23:57:52 +0000
Subject: [issue18080] setting CC no longer overrides default linker for
 extension module builds on OS X
In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za>
Message-ID: <1593907072.33.0.300625160652.issue18080@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Well, the issue is potentially ignorable, especially if distutils is deprecated and removed from CPython. Alternately, CPython could adopt the [patch from distutils](https://github.com/pypa/distutils/pull/1/commits/c3a052aefbba0d5fda10790e676223c0dc12f0ed) that corrects the issue. Would you like me to file a separate bug for this issue? Or apply that patch? Or something else?

----------

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

From report at bugs.python.org  Sat Jul  4 20:08:25 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 00:08:25 +0000
Subject: [issue31898] Add a `recommended-packages.txt` file
In-Reply-To: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>
Message-ID: <1593907705.35.0.636622037872.issue31898@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Sat Jul  4 20:13:46 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jul 2020 00:13:46 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593908026.82.0.590694590846.issue40874@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Thanks for the clarification.  I agree this does not seem to be a very big deal, if slightly annoying for the packager who will have to deal with it.

----------

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

From report at bugs.python.org  Sat Jul  4 20:22:53 2020
From: report at bugs.python.org (Joseph Hackman)
Date: Sun, 05 Jul 2020 00:22:53 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1593908573.86.0.24741161469.issue32958@roundup.psfhosted.org>


Joseph Hackman <josephhackman at gmail.com> added the comment:

According to the DNS standard, hostnames with more than 63 characters per label (the sections between .) are not allowed [https://tools.ietf.org/html/rfc1035#section-2.3.1].

That said, enforcing that at the codec level might be the wrong choice. I threw together a quick patch moving the limits up to 250, and nothing blew up. It's unclear what the general usefulness of such a change would be, since DNS servers probably couldn't handle those requests anyway.

As for the original issue, if anybody is still doing something like that, could they provide a full example URL? I was unable to reproduce on HTTP (failed in a different place), or FTP.

----------
nosy: +joseph.hackman

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

From report at bugs.python.org  Sat Jul  4 20:51:17 2020
From: report at bugs.python.org (James McCorkindale)
Date: Sun, 05 Jul 2020 00:51:17 +0000
Subject: [issue41209] Scripts Folder is Empty
Message-ID: <1593910277.95.0.176606187377.issue41209@roundup.psfhosted.org>


New submission from James McCorkindale <jamesmccorkindale0 at gmail.com>:

The Scripts folder is empty and I'm not sure what's wrong. I'm trying to install modules and looked it up on the internet and I think I need this folder not to be empty. How should i fix this?

Thanks, James

----------
components: Windows
messages: 373007
nosy: Jamesss04, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Scripts Folder is Empty
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Jul  4 21:13:45 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 01:13:45 +0000
Subject: [issue14189] C API documentation must document if returned object is
 a borrowed reference or strong reference
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1593911625.59.0.120650107314.issue14189@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Sat Jul  4 21:28:46 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Sun, 05 Jul 2020 01:28:46 +0000
Subject: [issue32561] Add API to io objects for cache-only reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1593912526.19.0.776771084649.issue32561@roundup.psfhosted.org>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

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

From report at bugs.python.org  Sat Jul  4 21:33:04 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Sun, 05 Jul 2020 01:33:04 +0000
Subject: [issue13322] The io module doesn't support non-blocking files
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1593912784.28.0.402639689997.issue13322@roundup.psfhosted.org>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

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

From report at bugs.python.org  Sat Jul  4 21:51:25 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Sun, 05 Jul 2020 01:51:25 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
Message-ID: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>


New submission from Hiroshi Miura <miurahr at linux.com>:

When decompressing a particular archive, result become truncated a last word. 
A test data attached is uncompressed size is 12800 bytes, and compressed using LZMA1+BCJ algorithm into 11327 bytes.
The data is a payload of a 7zip archive.

Here is a pytest code to reproduce it.


:: code-block::

    def test_lzma_raw_decompressor_lzmabcj():
        filters = []
        filters.append({'id': lzma.FILTER_X86})
        filters.append(lzma._decode_filter_properties(lzma.FILTER_LZMA1, b']\x00\x00\x01\x00'))
        decompressor = lzma.LZMADecompressor(format=lzma.FORMAT_RAW, filters=filters)
        with testdata_path.joinpath('lzmabcj.bin').open('rb') as infile:
            out = decompressor.decompress(infile.read(11327))
        assert len(out) == 12800


test become failure that len(out) become 12796 bytes, which lacks last 4 bytes, which should be b'\x00\x00\x00\x00'
When specifying  a filters  as a single LZMA1 decompression,  I got an expected length of data, 12800 bytes.(*1)

When creating a test data with LZMA2+BCJ and examines it, I got an expected data.
When specifying a filters as a single LZMA2 decompression against LZMA2+BCJ payload, a result is perfectly as same as (*1) data.
It indicate us that a pipeline of LZMA1/LZMA2 --> BCJ is in doubt. 


After investigation and understanding that _lzmamodule.c is a thin wrapper of liblzma, I found the problem can be reproduced in liblzma.
I've reported it to upstream xz-devel ML with a test code https://www.mail-archive.com/xz-devel at tukaani.org/msg00370.html

----------
components: Extension Modules
files: lzmabcj.bin
messages: 373008
nosy: miurahr
priority: normal
severity: normal
status: open
title: LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is paticular LZMA+BCJ  data
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49296/lzmabcj.bin

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

From report at bugs.python.org  Sat Jul  4 22:30:28 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 02:30:28 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593916228.19.0.813714920551.issue26205@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
nosy: +nanjekyejoannah
nosy_count: 8.0 -> 9.0
pull_requests: +20474
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21324

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

From report at bugs.python.org  Sat Jul  4 22:41:26 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 02:41:26 +0000
Subject: [issue12165] Nonlocal does not include global; clarify doc
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1593916886.69.0.590273489498.issue12165@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah
stage:  -> needs patch

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

From report at bugs.python.org  Sat Jul  4 22:53:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jul 2020 02:53:03 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
Message-ID: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>


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

```
.. c:function:: PyObject* PyLong_FromUnicodeObject(PyObject *u, int base)

   Convert a sequence of Unicode digits in the string *u* to a Python integer
   value.  The Unicode string is first encoded to a byte string using
   :c:func:`PyUnicode_EncodeDecimal` and then converted using
   :c:func:`PyLong_FromString`.
```

PyUnicode_EncodeDecimal is not used actually.
It uses private and undocumented `_PyUnicode_TransformDecimalAndSpaceToASCII` function instead.

The document of PyFloat_FromString() doesn't mention about how it convert unicode string to digits. Let's remove the second sentence.

----------
assignee: docs at python
components: Documentation
messages: 373009
nosy: docs at python, inada.naoki
priority: normal
severity: normal
status: open
title: PyLong_FromUnicodeObject document is wrong
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jul  4 22:54:51 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jul 2020 02:54:51 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593917691.41.0.260608897914.issue41211@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Jul  4 23:39:39 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 03:39:39 +0000
Subject: [issue23802] patch: __deepcopy__ memo dict argument usage
In-Reply-To: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>
Message-ID: <1593920379.48.0.10356834141.issue23802@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah
nosy_count: 3.0 -> 4.0
pull_requests: +20476
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21326

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

From report at bugs.python.org  Sat Jul  4 23:59:10 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 05 Jul 2020 03:59:10 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1593921550.33.0.830726894012.issue39168@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +20477
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21327

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

From report at bugs.python.org  Sun Jul  5 00:02:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 04:02:01 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593921721.1.0.766236781571.issue41211@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20478
pull_request: https://github.com/python/cpython/pull/21328

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

From report at bugs.python.org  Sun Jul  5 00:01:51 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jul 2020 04:01:51 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593921711.62.0.330456057761.issue41211@roundup.psfhosted.org>


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


New changeset 9c8441712230660fedac818ed50e7cdd89e4c51d by Inada Naoki in branch 'master':
bpo-41211: Doc: Fix PyLong_FromUnicodeObject (GH-21325)
https://github.com/python/cpython/commit/9c8441712230660fedac818ed50e7cdd89e4c51d


----------

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

From report at bugs.python.org  Sun Jul  5 00:02:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 04:02:08 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593921728.31.0.252424592295.issue41211@roundup.psfhosted.org>


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


----------
pull_requests: +20479
pull_request: https://github.com/python/cpython/pull/21329

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

From report at bugs.python.org  Sun Jul  5 00:07:13 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 04:07:13 +0000
Subject: [issue32192] Provide importlib.util.lazy_import helper function
In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za>
Message-ID: <1593922033.56.0.0962432173888.issue32192@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
nosy: +nanjekyejoannah
nosy_count: 5.0 -> 6.0
pull_requests: +20480
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21330

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

From report at bugs.python.org  Sun Jul  5 00:08:42 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 04:08:42 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593922122.27.0.61183976942.issue41211@roundup.psfhosted.org>


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


New changeset 48f388f02f000fb9087a854c0dc77ce39bc2bb29 by Miss Islington (bot) in branch '3.9':
bpo-41211: Doc: Fix PyLong_FromUnicodeObject (GH-21325)
https://github.com/python/cpython/commit/48f388f02f000fb9087a854c0dc77ce39bc2bb29


----------

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

From report at bugs.python.org  Sun Jul  5 00:09:21 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 04:09:21 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593922161.4.0.946188636885.issue41211@roundup.psfhosted.org>


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


New changeset 4874e5908c38da4c7dcaecf6397832dda1e6dd08 by Miss Islington (bot) in branch '3.8':
bpo-41211: Doc: Fix PyLong_FromUnicodeObject (GH-21325)
https://github.com/python/cpython/commit/4874e5908c38da4c7dcaecf6397832dda1e6dd08


----------

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

From report at bugs.python.org  Sun Jul  5 00:14:25 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jul 2020 04:14:25 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593922465.8.0.456358393286.issue41211@roundup.psfhosted.org>


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


----------
pull_requests: +20481
pull_request: https://github.com/python/cpython/pull/21331

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

From report at bugs.python.org  Sun Jul  5 00:48:49 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 05 Jul 2020 04:48:49 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1593924529.39.0.950461355784.issue39168@roundup.psfhosted.org>


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

Should this be backported? How far back?

----------

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

From report at bugs.python.org  Sun Jul  5 01:07:48 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 05:07:48 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1593925668.82.0.63607982755.issue39168@roundup.psfhosted.org>


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


New changeset 7fed75597fac11f9a6c769e2b6c6548fe0e4049d by Zackery Spytz in branch 'master':
bpo-39168: Remove the __new__ method of typing.Generic (GH-21327)
https://github.com/python/cpython/commit/7fed75597fac11f9a6c769e2b6c6548fe0e4049d


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

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

From report at bugs.python.org  Sun Jul  5 01:28:48 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jul 2020 05:28:48 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593926928.36.0.433756182777.issue41211@roundup.psfhosted.org>


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


New changeset 16f451744b7f4653ca9db4b4bedbb6fc5c0de154 by Inada Naoki in branch '3.9':
bpo-41211: Doc: Fix PyLong_FromUnicode (GH-21331)
https://github.com/python/cpython/commit/16f451744b7f4653ca9db4b4bedbb6fc5c0de154


----------

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

From report at bugs.python.org  Sun Jul  5 01:28:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 05:28:52 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593926932.04.0.926090106737.issue41211@roundup.psfhosted.org>


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


----------
pull_requests: +20482
pull_request: https://github.com/python/cpython/pull/21332

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

From report at bugs.python.org  Sun Jul  5 01:36:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 05:36:01 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593927361.6.0.409619168362.issue41211@roundup.psfhosted.org>


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


New changeset 01c0925271a9e8c6a4b316efeb8fdcbed9eb17f4 by Miss Islington (bot) in branch '3.8':
bpo-41211: Doc: Fix PyLong_FromUnicode (GH-21331)
https://github.com/python/cpython/commit/01c0925271a9e8c6a4b316efeb8fdcbed9eb17f4


----------

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

From report at bugs.python.org  Sun Jul  5 01:38:57 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jul 2020 05:38:57 +0000
Subject: [issue41211] PyLong_FromUnicodeObject document is wrong
In-Reply-To: <1593917583.65.0.783056936428.issue41211@roundup.psfhosted.org>
Message-ID: <1593927537.13.0.160544728861.issue41211@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jul  5 02:41:21 2020
From: report at bugs.python.org (Big Stone)
Date: Sun, 05 Jul 2020 06:41:21 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1593931281.2.0.44596837509.issue40741@roundup.psfhosted.org>


Big Stone <stonebig34 at gmail.com> added the comment:

hello,

Python-3.8.4rc1 and Python-3.9.0b4 are still with SQLite-3.31.1. 

Is it expected ?

----------
nosy: +Big Stone

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

From report at bugs.python.org  Sun Jul  5 04:05:03 2020
From: report at bugs.python.org (pmp-p)
Date: Sun, 05 Jul 2020 08:05:03 +0000
Subject: [issue41111] Convert a few stdlib extensions to the limited C API
In-Reply-To: <1593075260.88.0.835474638855.issue41111@roundup.psfhosted.org>
Message-ID: <1593936303.18.0.892776373728.issue41111@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

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

From report at bugs.python.org  Sun Jul  5 04:32:00 2020
From: report at bugs.python.org (LtWorf)
Date: Sun, 05 Jul 2020 08:32:00 +0000
Subject: [issue39765] asyncio loop.add_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1593937920.52.0.655083837858.issue39765@roundup.psfhosted.org>


LtWorf <tiposchi at tiscali.it> added the comment:

This looks related to: https://bugs.python.org/issue32443

----------
nosy: +tiposchi

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

From report at bugs.python.org  Sun Jul  5 04:41:53 2020
From: report at bugs.python.org (Ben Griffin)
Date: Sun, 05 Jul 2020 08:41:53 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
Message-ID: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>


New submission from Ben Griffin <ben at redsnapper.net>:

https://stackoverflow.com/questions/62713741/tkinter-and-32-bit-unicode-duplicating-any-fix

Emoji are doubling up when using canvas.create_text()
This is reported to work on tcl/tk 8.6.10 but there?s no. Way to upgrade tcl/tk using the standard installs from the python.org site

----------
components: Tkinter
files: Emoji.py.txt
messages: 373019
nosy: Ben Griffin
priority: normal
severity: normal
status: open
title: Emoji Unicode failing in standard release of Python 3.8.3 / tkinter 8.6.8
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49297/Emoji.py.txt

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

From report at bugs.python.org  Sun Jul  5 05:03:05 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 05 Jul 2020 09:03:05 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1593939785.45.0.848111845982.issue41212@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Sun Jul  5 05:09:23 2020
From: report at bugs.python.org (Amine)
Date: Sun, 05 Jul 2020 09:09:23 +0000
Subject: [issue41213] Cannot locate MSBuild.exe on PATH or as MSBUILD variable
Message-ID: <1593940163.76.0.968846019884.issue41213@roundup.psfhosted.org>


New submission from Amine <tbaik.amine at gmail.com>:

I am running windows10. I HAVE to use python 3.6 for a project
downloaded it and followed the instructions in PCBuild/readme.txt
and I got the following output: (I would like to mention i checked this issue #33675 but I had no idea what is it talking about, am not using a "Buildbot")

C:\Users\Amine\Downloads\Python-3.6.11\Python-3.6.11\PCbuild>build.bat -e
Using "C:\Users\Amine\Downloads\Python-3.6.11\Python-3.6.11\PCbuild\\..\externals\pythonx86\tools\python.exe" (found in externals directory)      
Fetching external libraries...
bzip2-1.0.6 already exists, skipping.
openssl-1.0.2q already exists, skipping.
sqlite-3.21.0.0 already exists, skipping.
tcl-core-8.6.6.0 already exists, skipping.
tk-8.6.6.0 already exists, skipping.
tix-8.4.3.6 already exists, skipping.
xz-5.2.2 already exists, skipping.
Fetching external binaries...
nasm-2.11.06 already exists, skipping.
Finished.
Cannot locate MSBuild.exe on PATH or as MSBUILD variable

C:\Users\Amine\Downloads\Python-3.6.11\Python-3.6.11\PCbuild>

----------
components: Windows
messages: 373020
nosy: Amen8, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot locate MSBuild.exe on PATH or as MSBUILD variable
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Sun Jul  5 05:26:19 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 05 Jul 2020 09:26:19 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1593941179.14.0.902856385767.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Thanks for taking a look, Antoine.

IIRC, the version pinning already accommodates Debian:

#if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x02050000
  #error "libmpdec version >= 2.5.0 required"
#endif


In the first libmpdec versions, I had a stricter equality check,
and I *think* (but I'm not 100% sure) that it was Matthias who
requested the relaxation.


Based on that, perhaps Debian should just use 2.5.0 for both
3.8 and 3.9 in the transition period.


I'm more comfortable with 3.8 using 2.5.0 than 3.9 using 2.4.2.

----------

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

From report at bugs.python.org  Sun Jul  5 05:27:44 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 05 Jul 2020 09:27:44 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593941264.95.0.214171298364.issue26205@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Just to point out: it can be more than four, right? If you have a function aa within a function bb within a function cc, then bb's and cc's scope are different, even though functionally equivalent from the perspective of aa.

----------
nosy: +veky

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

From report at bugs.python.org  Sun Jul  5 05:31:13 2020
From: report at bugs.python.org (Amine)
Date: Sun, 05 Jul 2020 09:31:13 +0000
Subject: [issue41213] Cannot locate MSBuild.exe on PATH or as MSBUILD variable
In-Reply-To: <1593940163.76.0.968846019884.issue41213@roundup.psfhosted.org>
Message-ID: <1593941473.35.0.475439850461.issue41213@roundup.psfhosted.org>


Amine <tbaik.amine at gmail.com> added the comment:

I added the path manually to env variables. and this particular issue has been resolved

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

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

From report at bugs.python.org  Sun Jul  5 06:17:23 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Jul 2020 10:17:23 +0000
Subject: [issue36302] distutils creates unreproducible .so files
In-Reply-To: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org>
Message-ID: <1593944243.82.0.523122434837.issue36302@roundup.psfhosted.org>


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

An unfortunate side effect of this change is that changes the build order even if the source list order is relevant. 

In particular, I sort the source list by age when working on larger extensions, this makes sure that the source files I edited last get compiled first, which speeds up edit/build cycles.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Jul  5 06:41:30 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Jul 2020 10:41:30 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1593945690.94.0.662203451357.issue41212@roundup.psfhosted.org>


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


----------
assignee:  -> ned.deily

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

From report at bugs.python.org  Sun Jul  5 06:48:03 2020
From: report at bugs.python.org (Ma Lin)
Date: Sun, 05 Jul 2020 10:48:03 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1593946083.5.0.44734765188.issue41210@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
components: +Library (Lib) -Extension Modules
nosy: +malin

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

From report at bugs.python.org  Sun Jul  5 06:53:50 2020
From: report at bugs.python.org (Peter Wu)
Date: Sun, 05 Jul 2020 10:53:50 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1593946430.6.0.249204120553.issue14156@roundup.psfhosted.org>


Peter Wu <peter at lekensteyn.nl> added the comment:

I just ran into this issue on Linux when piping a binary file to stdin resulted in a UnicodeDecodeError while trying to read a byte from the stream. Passing /dev/stdin is a workaround that does not require modifications to an application.

As for the proposed PR 13165, I'd suggest to gracefully fallback to normal stdout/stdin if the buffer is not available. That approach is also followed in the fileinput module, and takes care of the note for library developers in the documentation at https://docs.python.org/3/library/sys.html#sys.stdin

Not feeling particular strong about the graceful handling, but I hope that the test code can be simplified in that case.

----------
nosy: +lekensteyn

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

From report at bugs.python.org  Sun Jul  5 06:54:27 2020
From: report at bugs.python.org (Vincent LE GARREC)
Date: Sun, 05 Jul 2020 10:54:27 +0000
Subject: [issue41214] -O0: Segmentation fault in _PyArg_UnpackStack
Message-ID: <1593946467.6.0.0689011340862.issue41214@roundup.psfhosted.org>


New submission from Vincent LE GARREC <legarrec.vincent at gmail.com>:

In Gentoo, I compile my system with -O0

When I compile Apache Serf, python 3.7.8 crashes. When I compile python 3.7 with -O2, python don't crash when compiling Serf.

It's the first time that -O0 causes program crash.

I run test suite, I don't have any problem.

Please find enclosed the backtrace.

I can reproduce every time so if you want me to do some tests, I can do it.

I already report it to Gentoo (https://bugs.gentoo.org/730312) but it seems it's not related to them.

----------
files: backtrace.log.gz
messages: 373026
nosy: Vincent LE GARREC
priority: normal
severity: normal
status: open
title: -O0: Segmentation fault in _PyArg_UnpackStack
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49298/backtrace.log.gz

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

From report at bugs.python.org  Sun Jul  5 07:00:17 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 11:00:17 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1593946817.48.0.382638306926.issue39168@roundup.psfhosted.org>


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


----------
pull_requests: +20483
pull_request: https://github.com/python/cpython/pull/21335

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

From report at bugs.python.org  Sun Jul  5 07:31:23 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 05 Jul 2020 11:31:23 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
Message-ID: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

As the bots were both running - based on gcc - this was not noticed immediately.

issue40334 implements PEP 617, the new PEG parser for CPython.

Using bisect I located:

commit c5fc15685202cda73f7c3f5c6f299b0945f58508 (HEAD, refs/bisect/bad)
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Wed Apr 22 23:29:27 2020 +0100

    bpo-40334: PEP 617 implementation: New PEG parser for CPython (GH-19503)

    Co-authored-by: Guido van Rossum <guido at python.org>
    Co-authored-by: Lysandros Nikolaou <lisandrosnik at gmail.com>

+++ the make status (abbreviated) is:
root at x066:[/data/prj/python/py39-3.10]slibclean; rm -rf *; buildaix --without-computed-gotos; print; date; ./python -E -S -m sysconfig --generate-posix-vars; ./python
+ CPPFLAGS="-I/opt/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5"\
        ../git/py39-3.10/configure\
                --prefix=/opt \
                --sysconfdir=/var/py39/etc\
                --sharedstatedir=/var/py39/com\
                --localstatedir=/var/py39\
                --mandir=/usr/share/man\
                --infodir=/opt/share/info/py39 --without-computed-gotos\
                        > .buildaix/configure.out
+ /usr/bin/make > .buildaix/make.out
    1500-016: (W) WARNING: Compiler problem occurred while compiling _PyPegen_clear_memo_statistics: A file or directory in the path name does not exist..
    1500-034: (S) Cannot create object file.
make: 1254-004 The error code from the last command is 1.

+++ The complete make.out (stdout) is:
root at x066:[/data/prj/python/py39-3.10]cat .buildaix/make*
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Programs/python.o ../git/py39-3.10/Programs/python.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/acceler.o ../git/py39-3.10/Parser/acceler.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/grammar1.o ../git/py39-3.10/Parser/grammar1.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/listnode.o ../git/py39-3.10/Parser/listnode.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/node.o ../git/py39-3.10/Parser/node.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/parser.o ../git/py39-3.10/Parser/parser.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/token.o ../git/py39-3.10/Parser/token.c
        xlc_r -c  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5    -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include  -DPy_BUILD_CORE -o Parser/pegen/pegen.o ../git/py39-3.10/Parser/pegen/pegen.c

*******
After 
commit a25f3c4c8f7d4878918ce1d3d67db40ae255ccc6 (HEAD)
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Thu Apr 23 01:38:11 2020 +0100

    bpo-40334: Fix builds outside the source directory and regenerate autoconf files (GH-19667)

/bin/sh: 7405692 Segmentation fault(coredump)
make: 1254-004 The error code from the last command is 139.


Stop.
/usr/bin/make returned an error

Sun Jul  5 11:23:39 UTC 2020
Segmentation fault(coredump)
Python 3.9.0a5+ (default, Jul  5 2020, 11:23:33) [C] on aix
Type "help", "copyright", "credits" or "license" for more information.

***********
The above includes 

aixtools at x064:[/data/prj/python/git/py39-3.10]git checkout 458004bf7914f96b20bb76bc3584718cf83f652e
Previous HEAD position was a25f3c4c8f bpo-40334: Fix builds outside the source directory and regenerate autoconf files (GH-19667)
HEAD is now at 458004bf79 bpo-40334: Fix errors in parse_string.c with old compilers (GH-19666)

This still crashes with the message:

    1500-016: (W) WARNING: Compiler problem occurred while compiling _PyPegen_clear_memo_statistics: A file or directory in the path name does not exist..
    1500-034: (S) Cannot create object file.

************

I'll add more debug info in a followup - starting at:

Previous HEAD position was a25f3c4c8f bpo-40334: Fix builds outside the source directory and regenerate autoconf files (GH-19667)

----------
components: Build
messages: 373027
nosy: David.Edelsohn, Michael.Felt, pablogsal
priority: normal
severity: normal
status: open
title: AIX: build fails for xlc/xlC since new PEG parser
type: compile error
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sun Jul  5 07:32:57 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 05 Jul 2020 11:32:57 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593948777.23.0.124532126717.issue41215@roundup.psfhosted.org>


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


----------
nosy: +skrah

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

From report at bugs.python.org  Sun Jul  5 07:45:39 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Jul 2020 11:45:39 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1593949539.92.0.171444924706.issue39542@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Good catch, Raymond. I'll mark this as a release blocker to ensure I don't miss it. The last beta is scheduled for July 20th. Is this enough time for you? I would very much like to avoid refactors of any sort during the release candidate stage.

----------
priority: high -> release blocker
resolution: fixed -> 

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

From report at bugs.python.org  Sun Jul  5 08:30:07 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Sun, 05 Jul 2020 12:30:07 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593549875.63.0.81357373837.issue41176@roundup.psfhosted.org>
Message-ID: <1593952207.23.0.486991664824.issue41176@roundup.psfhosted.org>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

I'd like to consider one more possibility for future behavior that sort of came to mind while discussing the PR. In current behavior, it is possible to use `willdispatch` to trick `WaitForMainloop` into letting a thread pass through the timeout, where it will eventually wait on a `Tcl_ConditionWait` in `Tkapp_ThreadSend`. 

This could be very efficient default behavior, since no polling is required; the thread just goes when the loop comes up. Is it possible to make this a well-documented feature and default behavior of tkinter? Or would it be too surprising for new and existing users? It would be important to make sure that threads aren't silently getting lost in old programs and new users can figure out they need to call `mainloop`, `doonevent`, or `update` when not on the REPL or the thread will hang.

----------

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

From report at bugs.python.org  Sun Jul  5 09:40:04 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 05 Jul 2020 13:40:04 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593956404.71.0.055479495148.issue41215@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Well, the first step -s just showing where the segmentation fault occurs (in pegen.c).

I am not really 'wiser' in what I should be looking at. I'll try adding a fprintf(stderr, ....) to see if I can figure out a bit more.

For the experts:

(dbx) where
strncmp(??, ??, ??) at 0xd011d920
_get_keyword_or_name_type(p = 0x00000023, name = warning: Unable to access address 0xd from core
(invalid char ptr (0x0000000d)), name_len = 0), line 503 in "pegen.c"
_PyPegen_fill_token(p = 0x1025f138), line 546 in "pegen.c"
_PyPegen_expect_token(p = (nil), type = 805759776), line 675 in "pegen.c"
_tmp_6_rule at AF486_140(??), line 10251 in "parse.c"
_PyPegen_lookahead(positive = 269294544, func = 0x3001da40, p = 0x2ff20f30), line 666 in "pegen.c"
compound_stmt_rule at AF476_280(??), line 1232 in "parse.c"
statement_rule at AF477_284(??), line 795 in "parse.c"
unnamed block in _loop1_2_rule(p = 0x30085830), line 10086 in "parse.c"
_loop1_2_rule(p = 0x30085830), line 10086 in "parse.c"
statements_rule at AF478_285(??), line 766 in "parse.c"
file_rule at AF479_289(??), line 646 in "parse.c"
_PyPegen_run_parser(p = 0x30085820), line 916 in "pegen.c"
_PyPegen_run_parser_from_string(str = "compile", start_rule = 272032944, filename_ob = 0x20084f68, iflags = 805427776, arena = 0x30085820), line 1024 in "pegen.c"
PyPegen_ASTFromStringObject(str = (nil), filename = (nil), mode = 804393472, flags = 0x20035cb0, arena = 0x102453c4), line 26 in "peg_api.c"
unnamed block in Py_CompileStringObject(str = "|p^[yN", filename = (nil), start = 0, flags = 0x3007bbc8, optimize = -2147483647), line 1244 in "pythonrun.c"
Py_CompileStringObject(str = "|p^[yN", filename = (nil), start = 0, flags = 0x3007bbc8, optimize = -2147483647), line 1244 in "pythonrun.c"
builtin_compile_impl(module = (nil), source = 0x20000bd8, filename = 0x20063c48, mode = "\320Qf", flags = 1, dont_inherit = 536873648, optimize = 804393760, feature_version = 537275800), line 823 in "bltinmodule.c"
builtin_compile(module = 0x2ff21460, args = 0x3007fa78, nargs = 2, kwnames = 0x30007470), line 274 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x100b203c, args = 0x00000003, nargsf = 804394000, kwnames = 0x20047844), line 396 in "methodobject.c"
PyVectorcall_Call(callable = 0x100b2e10, tuple = 0x20026f40, kwargs = 0x2ff21470), line 255 in "call.c"
_PyObject_Call(tstate = 0x100b1d1c, callable = 0x30002870, args = 0x2ff214c0, kwargs = 0x30043fd0), line 265 in "call.c"
do_call_core(tstate = 0x00000001, func = 0x30094050, callargs = 0x30046428, kwdict = 0x300462e8), line 5054 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x3009315c, f = 0x30043e58, throwflag = -261800280), line 3542 in "ceval.c"
_PyEval_EvalCode(tstate = 0x3005d820, _co = 0x3003a6a0, globals = 0x2ff216d0, locals = 0x422822cc, args = 0x100b46e4, argcount = 805410760, kwnames = 0x2ff216d0, kwargs = 0x20047844, kwcount = 2, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8, qualname = 0x300197c8), line 41 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x100d3714, stack = 0x3008ea08, nargsf = 804394848, kwnames = 0x20047844), line 411 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0xffffffff, f = 0x300834c8, throwflag = 804395040), line 487 in "abstract.h"
_PyEval_EvalCode(tstate = 0x300865b0, _co = 0x30061b88, globals = 0x2ff218e0, locals = 0x5328333f, args = 0x10073d54, argcount = 537279560, kwnames = 0x2ff218e0, kwargs = 0x20047844, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = 0x3006bb90, closure = (nil), name = 0x30061b88, qualname = 0x3004eb10), line 41 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x30092f50, stack = 0x30004048, nargsf = 804395376, kwnames = (nil)), line 411 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x100759a4, f = (nil), throwflag = 804395568), line 487 in "abstract.h"
function_code_fastcall(tstate = 0x300418bc, co = (nil), args = 0x3000c220, nargs = 805664616, globals = (nil)), line 41 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x100759a4, f = 0x30087c08, throwflag = 804395904), line 487 in "abstract.h"
function_code_fastcall(tstate = 0x30086520, co = 0x3004c070, args = 0x2000abe8, nargs = 1, globals = 0x30049ec0), line 41 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x00000001, throwflag = 804396240), line 487 in "abstract.h"
function_code_fastcall(tstate = 0x3004389c, co = 0x30031176, args = 0x30031160, nargs = 805626736, globals = (nil)), line 41 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x100759a4, f = 0x20063c48, throwflag = 804396576), line 487 in "abstract.h"
function_code_fastcall(tstate = 0x00000082, co = 0x00000087, args = 0x2ff21e90, nargs = 0, globals = 0x3004c070), line 41 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x102f4474, f = (nil), throwflag = 804397104), line 487 in "abstract.h"
function_code_fastcall(tstate = 0x3004ca50, co = 0x3004c688, args = 0x2ff21ff0, nargs = 537163844, globals = 0x10073e78), line 41 in "pycore_ceval.h"
object_vacall(tstate = 0x20062d98, base = 0x20063c48, callable = 0x2ff22050, vargs = warning: Unable to access address 0x482822cf from core
(invalid char ptr (0x482822cf))), line 62 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = (nil), name = 0x20025dc0, ... = 0x3008d778, 0x3003c488, 0x0, 0x3003ad88, 0x3003acc8, 0x3003ace8), line 895 in "call.c"
import_find_and_load(tstate = 0x2004185c, abs_name = (nil)), line 1767 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30084d70, globals = (nil), locals = 0x103b2490, fromlist = 0x2003acc8, level = 804397488), line 1881 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30084d70, globals = (nil), locals = 0x103b2490, fromlist = 0x2003acc8, level = 804397488), line 1881 in "import.c"
builtin___import__(self = 0x100bde94, args = 0x00000010, kwds = 0x2ff22220), line 280 in "bltinmodule.c"
cfunction_call(func = 0x20063c48, args = 0x3003c3e8, kwargs = (nil)), line 464 in "methodobject.c"
_PyObject_MakeTpCall(tstate = (nil), callable = 0x2ff2235c, args = 0x2ff22300, nargs = 673718991, keywords = 0x100bbd94), line 191 in "call.c"
_PyObject_CallFunctionVa(tstate = 0x61f122d6, callable = (nil), format = warning: Unable to access address 0xdeadbeef from core
(invalid char ptr (0xdeadbeef)), va = (nil), is_size_t = 0), line 65596 in "abstract.h"
PyObject_CallFunction(callable = 0x3003c488, format = "OOOOi", ... = 0x3008d778, 0x30084dc0, 0x30084dc0, 0x3006af48, 0x0, 0x0), line 577 in "call.c"
PyImport_Import(module_name = 0x2ff22540), line 2082 in "import.c"
PyImport_ImportModule(name = "\200A"), line 1485 in "import.c"
PyImport_ImportModuleNoBlock(name = "`"), line 1503 in "import.c"
_PyCodecRegistry_Init(), line 1541 in "codecs.c"
_PyCodec_Forget(encoding = warning: Unable to access address 0x61f122d6 from core
(invalid char ptr (0x61f122d6))), line 122 in "codecs.c"
init_stdio_encoding(tstate = 0x2ff22614), line 15915 in "unicodeobject.c"
init_fs_encoding(tstate = 0x20007e20), line 16028 in "unicodeobject.c"
_PyUnicode_InitEncodings(tstate = 0x2ff22730), line 16044 in "unicodeobject.c"
init_interp_main(tstate = 0x00000001), line 1006 in "pylifecycle.c"
pyinit_main(tstate = 0x200009f0), line 1097 in "pylifecycle.c"
Py_InitializeFromConfig(config = (nil)), line 1141 in "pylifecycle.c"
pymain_init(args = 0xf066a338), line 66 in "main.c"
pymain_main(args = 0x00000001), line 653 in "main.c"
Py_BytesMain(argc = -559038737, argv = 0xdeadbeef), line 686 in "main.c"
python.main(argc = 0, argv = (nil)), line 15 in "python.c"
(dbx)

(dbx) registers
  $r0:0xd011d900  $stkp:0x2ff20d40   $toc:0xf0648838    $r3:0x3fefffff
  $r4:0x200898bf    $r5:0x00000008    $r6:0x2000f098    $r7:0x00000012
  $r8:0x00556367    $r9:0x0a5f696d   $r10:0x80000000   $r11:0x7f7f7f7f
 $r12:0xf0641f5c   $r13:0x80000000   $r14:0x00000001   $r15:0x3004713c
 $r16:0x30047130   $r17:0x3003c668   $r18:0x20038844   $r19:0x30094078
 $r20:0x3007bbc8   $r21:0x3004642c   $r22:0x30046428   $r23:0x00000000
 $r24:0x20087710   $r25:0x00000012   $r26:0x00000001   $r27:0x00000005
 $r28:0x300a9980   $r29:0x2000f528   $r30:0x00000000   $r31:0x00000008
 $iar:0xd011d920   $msr:0x0000d032    $cr:0x44288468  $link:0x1025a524
 $ctr:0x00000008   $xer:0x00000010
          Condition status = 0:g 1:g 2:e 3:l 4:l 5:g 6:ge 7:l
        [unset $noflregs to view floating point registers]
        [unset $novregs to view vector registers]
        [unset $novsregs to view vector scalar registers]
in strncmp at 0xd011d920 ($t1)
0xd011d920 (strncmp+0x20) 88030001         lbz   r0,0x1(r3)

(dbx) listi strncmp
0xd011d900 (strncmp)      7c832040        cmpl   cr1,0x0,r3,r4
0xd011d904 (strncmp+0x4)  2c050000        cmpi   cr0,0x0,r5,0x0
0xd011d908 (strncmp+0x8)  4186003c         beq   cr1,0xd011d944 (strncmp+0x44)
0xd011d90c (strncmp+0xc)  3863ffff        addi   r3,-1(r3)
0xd011d910 (strncmp+0x10) 41820034         beq   0xd011d944 (strncmp+0x44)
0xd011d914 (strncmp+0x14) 3884ffff        addi   r4,-1(r4)
0xd011d918 (strncmp+0x18) 7ca903a6       mtctr   r5
0xd011d91c (strncmp+0x1c) 60210000         ori   r1,r1,0x0
0xd011d920 (strncmp+0x20) 88030001         lbz   r0,0x1(r3)
0xd011d924 (strncmp+0x24) 38630001        addi   r3,0x1(r3)

----------

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

From report at bugs.python.org  Sun Jul  5 10:42:30 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 05 Jul 2020 14:42:30 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593960150.14.0.0598717727693.issue41215@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

OK - merely added some fprintf statements.

When it is working as expected, the k->type values seem to be between 500 and 535 - when it fails the k->type value is frequently 9 digits (e.g., 537120904) - and it seems to never become -1 -- which would end the loop and "RETURN NAME".

One working example...

NAMEPTR: 20089d44, name_len:6 strlen(name):4472 name.16s:
import aliases



token: 20030d30, k_type:500, strlen(k->str):6 k->str.16s:
return

token: 20030d38, k_type:505, strlen(k->str):6 k->str.16s:
assert

token: 20030d40, k_type:508, strlen(k->str):6 k->str.16s:
global

token: 20030d48, k_type:513, strlen(k->str):6 k->str.16s:
import

RETURN k->type: 513 from k-str.16:import

And a failed (abbreviated) that ends with the segmentation error:

NAMEPTR: 20089d60, name_len:8 strlen(name):4444 name.16s:
_unknown = '--un

token: 2000f340, k_type:537120904, strlen(k->str):0 k->str.16s:


token: 2000f348, k_type:271488524, strlen(k->str):8 k->str.16s:
d  z?

token: 2000f350, k_type:805316552, strlen(k->str):0 k->str.16s:


token: 2000f358, k_type:368, strlen(k->str):11 k->str.16s:
__setitem__

token: 2000f360, k_type:537120928, strlen(k->str):8 k->str.16s:
<? z?

token: 2000f368, k_type:0, strlen(k->str):61 k->str.16s:
__setitem__($sel

token: 2000f370, k_type:271482672, strlen(k->str):0 k->str.16s:


...
token: 2000f730, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f738, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f740, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f748, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f750, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f758, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f760, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f768, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f770, k_type:271810528, strlen(k->str):0 k->str.16s:


token: 2000f778, k_type:0, strlen(k->str):0 k->str.16s:


token: 2000f780, k_type:271810512, strlen(k->str):4 k->str.16s:
real

token: 2000f788, k_type:0, strlen(k->str):0 k->str.16s:


/bin/sh: 8847524 Segmentation fault(coredump)
make: 1254-004 The error code from the last command is 139.


Hope this helps. I really do not know 'WHERE' it went wrong. I can only begin by guessing. So, expert guidance is appreciated!

----------

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

From report at bugs.python.org  Sun Jul  5 11:13:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jul 2020 15:13:29 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1593962009.44.0.853146244612.issue36346@roundup.psfhosted.org>


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

There is no need to deprecate _PyUnicode_AsUnicode. It is a private function. Undeprecating it will make the code clearer.

----------

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

From report at bugs.python.org  Sun Jul  5 11:18:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jul 2020 15:18:07 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1593962287.99.0.0834021542076.issue36346@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +20484
pull_request: https://github.com/python/cpython/pull/21336

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

From report at bugs.python.org  Sun Jul  5 11:20:26 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 05 Jul 2020 15:20:26 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1593962426.81.0.0334391320439.issue37207@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +20485
pull_request: https://github.com/python/cpython/pull/21337

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

From report at bugs.python.org  Sun Jul  5 11:28:06 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 05 Jul 2020 15:28:06 +0000
Subject: [issue40424] AIX: makexp_aix,
 parallel build (failures) and ld WARNINGS
In-Reply-To: <1588090800.25.0.961976947202.issue40424@roundup.psfhosted.org>
Message-ID: <1593962886.09.0.213464934935.issue40424@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks Kevin.

I took your patch (added your name to blurb as well).

Only difference was to remove Qsystem (or something), from the pathnames.

----------
versions: +Python 3.7

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

From report at bugs.python.org  Sun Jul  5 11:30:48 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Jul 2020 15:30:48 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1593963048.08.0.218275539097.issue41165@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Adding Miro since Fedora will be testing Python 3.10 and deprecated API removals here might potentially affect libraries like Python 3.9 testing.

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

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

From report at bugs.python.org  Sun Jul  5 11:53:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jul 2020 15:53:55 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1593964435.3.0.185974238549.issue36346@roundup.psfhosted.org>


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


New changeset b3dd5cd4a36877c473417fd7b3358843dcf8e647 by Serhiy Storchaka in branch 'master':
bpo-36346: Undeprecate private function _PyUnicode_AsUnicode(). (GH-21336)
https://github.com/python/cpython/commit/b3dd5cd4a36877c473417fd7b3358843dcf8e647


----------

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

From report at bugs.python.org  Sun Jul  5 12:02:45 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jul 2020 16:02:45 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1593964965.33.0.428876585182.issue39168@roundup.psfhosted.org>


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


New changeset 5a1384935ee8996a5bd240dd29f9b5e356cfc467 by Miss Islington (bot) in branch '3.9':
bpo-39168: Remove the __new__ method of typing.Generic (GH-21327)
https://github.com/python/cpython/commit/5a1384935ee8996a5bd240dd29f9b5e356cfc467


----------

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

From report at bugs.python.org  Sun Jul  5 12:03:53 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 05 Jul 2020 16:03:53 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1593965033.77.0.770689634523.issue39168@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Sun Jul  5 12:58:56 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 05 Jul 2020 16:58:56 +0000
Subject: [issue41195] Interface to OpenSSL's security level
In-Reply-To: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>
Message-ID: <1593968336.79.0.318884715614.issue41195@roundup.psfhosted.org>


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

Users can set the current security level in either an OpenSSL config file or with ctx.set_cipher("@SECLEVEL=i:...").

----------
versions: +Python 3.10

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

From report at bugs.python.org  Sun Jul  5 14:17:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jul 2020 18:17:08 +0000
Subject: [issue29727] collections.abc.Reversible doesn't fully support the
 reversing protocol
In-Reply-To: <1488739763.14.0.639498346483.issue29727@psf.upfronthosting.co.za>
Message-ID: <1593973028.93.0.219248669766.issue29727@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
nosy: +pablogsal
nosy_count: 5.0 -> 6.0
pull_requests: +20486
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21338

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

From report at bugs.python.org  Sun Jul  5 14:25:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jul 2020 18:25:50 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593973550.2.0.853907380499.issue41215@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +lys.nikolaou

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

From report at bugs.python.org  Sun Jul  5 14:27:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jul 2020 18:27:50 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593973670.03.0.810025178647.issue41215@roundup.psfhosted.org>


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

Unfortunately, I am having a hard time parsing your error description because is not immediate to distinguish:

- What is the error.
- Where does the error happen.
- How to reproduce the error.

Could you kindly provide more scoped information about these points so we can look into it?

----------

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

From report at bugs.python.org  Sun Jul  5 14:34:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jul 2020 18:34:37 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593974077.93.0.543214824609.issue41215@roundup.psfhosted.org>


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

Michael, can you try with this patch:

diff --git a/Parser/pegen.c b/Parser/pegen.c
index 53e3d49138..7faeec26ad 100644
--- a/Parser/pegen.c
+++ b/Parser/pegen.c
@@ -528,7 +528,7 @@ _get_keyword_or_name_type(Parser *p, const char *name, int name_len)
     if (name_len >= p->n_keyword_lists || p->keywords[name_len] == NULL) {
         return NAME;
     }
-    for (KeywordToken *k = p->keywords[name_len]; k->type != -1; k++) {
+    for (KeywordToken *k = p->keywords[name_len]; k != NULL && k->type != -1; k++) {
         if (strncmp(k->str, name, name_len) == 0) {
             return k->type;
         }


For whatever reasons, it seems that me are calling into _get_keyword_or_name_type with a name_len of 0.

----------

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

From report at bugs.python.org  Sun Jul  5 14:41:31 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jul 2020 18:41:31 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1593974491.87.0.845877398825.issue41208@roundup.psfhosted.org>


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


----------
nosy: +serhiy.storchaka, vstinner

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

From report at bugs.python.org  Sun Jul  5 15:36:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jul 2020 19:36:05 +0000
Subject: [issue21333] Document recommended exception for objects that
 shouldn't be pickled
In-Reply-To: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za>
Message-ID: <1593977765.96.0.142582986609.issue21333@roundup.psfhosted.org>


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

2.7 docs are no longer revised

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jul  5 15:36:44 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 05 Jul 2020 19:36:44 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593977804.94.0.998753478072.issue39960@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
pull_requests: +20487
pull_request: https://github.com/python/cpython/pull/21339

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

From report at bugs.python.org  Sun Jul  5 16:06:52 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 05 Jul 2020 20:06:52 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1593979612.14.0.697171596676.issue41212@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

This is a Tcl issue, as Tcl is designed for characters up to 16 bits. The fact that Chip is showing at all is very surprising, though any character outside of this 16-bit range should be considered unpredictable.

"The majority of characters used in the human languages of the world have character codes between 0 and 65535, and are known as the Basic Multilingual Plane  (BMP). Currently a default build of Tcl is only capable of handling these characters, but work is underway to change that, and workarounds requiring non-default build-time configuration options exist." [https://wiki.tcl-lang.org/page/Unicode]

----------
nosy: +epaine

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

From report at bugs.python.org  Sun Jul  5 16:09:02 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 20:09:02 +0000
Subject: [issue31305] 'pydoc -w import' report "no Python documentation found
 for 'import'"
In-Reply-To: <1536912870.64.0.956365154283.issue31305@psf.upfronthosting.co.za>
Message-ID: <1593979742.94.0.275861942801.issue31305@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Given EOL is this still relevant? as it is marked 2.7

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Sun Jul  5 16:12:12 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 05 Jul 2020 20:12:12 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593979932.36.0.501511611666.issue39960@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 8912c182455de83e27d5c120639ec91b18247913 by scoder in branch '3.8':
bpo-39960: Allow heap types in the "Carlo Verre" hack check that override "tp_setattro()" (GH-21092) (GH-21339)
https://github.com/python/cpython/commit/8912c182455de83e27d5c120639ec91b18247913


----------

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

From report at bugs.python.org  Sun Jul  5 16:17:22 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 05 Jul 2020 20:17:22 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593980242.18.0.362283664054.issue39960@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Fixed in 3.8+. Closing.
Thanks for the feedback.

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

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

From report at bugs.python.org  Sun Jul  5 16:37:12 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jul 2020 20:37:12 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1593981432.76.0.732544883368.issue41207@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In [pypa/distutils at 7aa5abeafc](https://github.com/pypa/distutils/commit/7aa5abeafc1e0b1b351c4c8ac7eb14c310366a46), I've pushed a fix (with a repro test in the parent commit). I recommend this fix be applied to CPython 3.9.

----------

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

From report at bugs.python.org  Sun Jul  5 16:39:27 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 20:39:27 +0000
Subject: [issue41018] warning: 'Tk_MainWindow' is deprecated: first deprecated
Message-ID: <1593981567.9.0.286119727843.issue41018@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

I find this issue to be less descriptive. Maybe a sentence to complement the title can help others understand even better.

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Sun Jul  5 16:59:05 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 05 Jul 2020 20:59:05 +0000
Subject: [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1593982745.06.0.826177730263.issue28681@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah
nosy_count: 8.0 -> 9.0
pull_requests: +20488
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21340

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

From report at bugs.python.org  Sun Jul  5 17:11:07 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jul 2020 21:11:07 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1593983467.74.0.395774227272.issue41207@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

CPython should also consider [this change](https://github.com/pypa/distutils/commit/d9ba43436d), which unifies the `DEBUG` handling, consolidates the exception trapping, and uses `subprocess.check_call` to re-use exit code checking.

----------

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

From report at bugs.python.org  Sun Jul  5 17:13:15 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jul 2020 21:13:15 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593983595.16.0.890379631991.issue26205@roundup.psfhosted.org>


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

At any one time, the language and interpreter sees the local scopes of enclosing functions as collectively 'nonlocal' for the purpose of accessing and rebinding.  If there are bindings of a name 'x' in multiple enclosing local scopes, the binding for 'x' in the synthesized 'nonlocal' is the innermost one.

----------

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

From report at bugs.python.org  Sun Jul  5 17:34:31 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 05 Jul 2020 21:34:31 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593984871.3.0.0842786797405.issue26205@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

How is that different from saying that "At any one time, the language and interpreter sees all the scopes as one scope for the purpose of accessing and rebinding."? Any ChainMap presents itself as a dictionary to the outside. That doesn't mean it doesn't have an internal structure.

Yes, nonlocal picks the innermost one because of its semantics, but it still needs to search through the scopes in order to know which one to pick, right?

----------

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

From report at bugs.python.org  Sun Jul  5 17:35:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jul 2020 21:35:37 +0000
Subject: [issue31305] 'pydoc -w import' report "no Python documentation found
 for 'import'"
In-Reply-To: <1536912870.64.0.956365154283.issue31305@psf.upfronthosting.co.za>
Message-ID: <1593984937.52.0.793640839211.issue31305@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)
type: behavior -> enhancement
versions: +Python 3.10 -Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun Jul  5 17:43:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jul 2020 21:43:17 +0000
Subject: [issue29727] collections.abc.Reversible doesn't fully support the
 reversing protocol
In-Reply-To: <1488739763.14.0.639498346483.issue29727@psf.upfronthosting.co.za>
Message-ID: <1593985397.38.0.628781289421.issue29727@roundup.psfhosted.org>


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


New changeset e51dd9dad6590bf3a940723fbbaaf4f64a3c9228 by Pablo Galindo in branch 'master':
bpo-29727: Register array.array as a MutableSequence (GH-21338)
https://github.com/python/cpython/commit/e51dd9dad6590bf3a940723fbbaaf4f64a3c9228


----------

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

From report at bugs.python.org  Sun Jul  5 17:43:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jul 2020 21:43:40 +0000
Subject: [issue29727] collections.abc.Reversible doesn't fully support the
 reversing protocol
In-Reply-To: <1488739763.14.0.639498346483.issue29727@psf.upfronthosting.co.za>
Message-ID: <1593985420.1.0.701370418899.issue29727@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Sun Jul  5 18:24:56 2020
From: report at bugs.python.org (Ben Griffin)
Date: Sun, 05 Jul 2020 22:24:56 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1593987896.49.0.164616245277.issue41212@roundup.psfhosted.org>


Ben Griffin <ben at redsnapper.net> added the comment:

Erm, I don?t rightly know how to parse epaine?s comment, as it seems to relate to a version of Unicode from over a decade ago, and a wiki page that was written 12 years ago.

IIRC Python 3 was (IMO rightly) developed to default to UTF-8, and according to a much more recently edited article (https://en.m.wikipedia.org/wiki/UTF-8), a normative UTF-8 parser can handle any of the million+ Unicode characters, including emoji.

As I pointed out in the bug report, and as mentioned by contributors on SO, TCL has seems to have fixed these issues by 8.6.10.

If epaine is correct and TCL CANTFIX/WONTFIX normative utf-8 - then maybe it?s time to drop the strong relationship that Python has with tkinter. However Im pretty sure that there is no need for such a drastic measure: the UTF-8 algorithm isn?t that complex.

----------

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

From report at bugs.python.org  Sun Jul  5 18:38:21 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 05 Jul 2020 22:38:21 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1593988701.62.0.992531665391.issue39960@roundup.psfhosted.org>


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

You're welcome. Hope this helps Cpython users.

----------

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

From report at bugs.python.org  Sun Jul  5 19:33:55 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 05 Jul 2020 23:33:55 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1593992035.4.0.574446918463.issue41215@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Iirc, my debug shows that k is not NULL, as k++ is not going to suddenly become smaller. And my debug shows it grows by a constant. 

My gut says the pointer to the base of the tokens is wrong, because the key types are such different values. Or do you know that those are valid types?

----------

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

From report at bugs.python.org  Sun Jul  5 20:31:03 2020
From: report at bugs.python.org (Andrej Klychin)
Date: Mon, 06 Jul 2020 00:31:03 +0000
Subject: [issue41216] eval don't load local variable in dict and list
 comprehensions.
Message-ID: <1593995463.39.0.732635658928.issue41216@roundup.psfhosted.org>


New submission from Andrej Klychin <andy_kl at bk.ru>:

I'm not sure is it a bug or a fecature of comprehensions or eval, but intuitively it seems like it should work.

def foo(baz):
    return eval("[baz for _ in range(10)]")

foo(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <listcomp>
NameError: name 'baz' is not defined

def bar(baz):
    return eval("{i: baz for i in range(10)}")

bar(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in bar
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <dictcomp>
NameError: name 'baz' is not defined

----------
components: Interpreter Core
messages: 373054
nosy: Andy_kl
priority: normal
severity: normal
status: open
title: eval don't load local variable in dict and list comprehensions.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Jul  5 20:52:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 00:52:41 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593996761.2.0.796452104586.issue26205@roundup.psfhosted.org>


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

Vedran: "How is that different from saying that "At any one time, the language and interpreter sees all the scopes as one scope for the purpose of accessing and rebinding."?"

For access, one may bypass the default staged access by specifying a specific namespace.  For rebinding elsewhere than in locals, one must specify one of the others.  So the 4 scopes are each visible.  However, the internal 'structure' of nonlocals is intentionally not visible or accessible.  (The proposal to make them somehow accessible was considered and rejected.)
---

The PR replaces 'at least three' with 'various'.  This is needlessly vague. There are always 3 namespaces and sometimes a 4th, so I think 'at least three' should be replaced with the specific '3 or 4'.

I rechecked two special cases.  Exception clauses with 'as name' bind name in the current local namespace and auto delete the binding when done.  Comprehensions bind the name and iterator of the 'for' clause in a temporary new local namespace, making the existing namespace temporarily part of a nonlocal namespace, which may or may not have been present before.  '3 or 4' still applies in both cases.

----------
versions: +Python 3.10 -Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Jul  5 20:58:53 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 00:58:53 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593997133.17.0.123020732172.issue26205@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

PR updated with your change. @Terry

----------

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

From report at bugs.python.org  Sun Jul  5 21:13:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 01:13:26 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593998006.22.0.942252235644.issue26205@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Inconsistency concerning nested scopes -> Better specify number of nested scopes

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

From report at bugs.python.org  Sun Jul  5 21:35:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 01:35:22 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1593999322.36.0.0823470923475.issue28681@roundup.psfhosted.org>


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

Vedran, thank you for the interesting cultural and linguistic perspective.  In Spanish, "Como te llamas?" (familiar) "Como se llama?" (formal) literally translate as "What do you call yourself?" (want me to call you?).  (I believe the latter could also be translated as "What are you called?", which you note is slightly different.  I also know that addressing people by name is a more involved -- and dangerous-- subject in Japan than in America.

I think that David's rewrite is clear enough with the little change I suggested at the end, and have approved Joannah's PR with one little addition.  Even if not perfect, it is definitely better than the current text.

----------
title: About function renaming in the tutorial -> Clarify multiple function names in the tutorial
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Jul  5 21:42:30 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 01:42:30 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593999750.92.0.403400140569.issue26205@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 9ed3cd8ba052b395ab50692bb65988b065d68e27 by Joannah Nanjekye in branch 'master':
bpo-26205: Specify the number of nested scopes (GH-21324)
https://github.com/python/cpython/commit/9ed3cd8ba052b395ab50692bb65988b065d68e27


----------

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

From report at bugs.python.org  Sun Jul  5 21:42:48 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 01:42:48 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593999768.64.0.657701504315.issue26205@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 10.0 -> 11.0
pull_requests: +20489
pull_request: https://github.com/python/cpython/pull/21341

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

From report at bugs.python.org  Sun Jul  5 21:42:55 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 01:42:55 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593999775.5.0.800343373708.issue26205@roundup.psfhosted.org>


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


----------
pull_requests: +20490
pull_request: https://github.com/python/cpython/pull/21342

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

From report at bugs.python.org  Sun Jul  5 21:45:24 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 01:45:24 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1593999924.41.0.607799164326.issue26205@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Merged, this can be closed if there is consesus.

----------

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

From report at bugs.python.org  Sun Jul  5 21:47:18 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 01:47:18 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1594000038.35.0.561737767932.issue28681@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset d12af71047f0eae86440654d3ea74c032c7c3558 by Joannah Nanjekye in branch 'master':
bpo-28681: Clarify multiple function names in the tutorial (GH-21340)
https://github.com/python/cpython/commit/d12af71047f0eae86440654d3ea74c032c7c3558


----------

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

From report at bugs.python.org  Sun Jul  5 21:47:35 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 01:47:35 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1594000055.43.0.409603063483.issue28681@roundup.psfhosted.org>


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


----------
pull_requests: +20492
pull_request: https://github.com/python/cpython/pull/21344

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

From report at bugs.python.org  Sun Jul  5 21:47:28 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 01:47:28 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1594000048.35.0.745241340717.issue28681@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jul  5 21:53:43 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 01:53:43 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594000423.61.0.489151548978.issue26205@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 7ceb3e3ffc8ee00551df2245544eb60f7debf3af by Miss Islington (bot) in branch '3.8':
bpo-26205: Specify the number of nested scopes (GH-21324) (GH-21342)
https://github.com/python/cpython/commit/7ceb3e3ffc8ee00551df2245544eb60f7debf3af


----------

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

From report at bugs.python.org  Sun Jul  5 21:59:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 01:59:02 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594000742.1.0.649096899194.issue26205@roundup.psfhosted.org>


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

I wait for backports to be merged before closing.  Someone has to approve them or manually merge them before that happens, so leaving issues open until all merges are done prevents totally forgetting about them.

For doc issues, the patch, if not drastically wrong, becomes the new status quo.  So I think any further proposed change should normally be a new issue.  So once the backports *are* done, you can close.

For code issues, 'drastically wrong' usually means that the patch failed on one of the buildbots, or fairly soon somewhere else, and needs either reversion or a hot fix.

----------
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jul  5 22:06:19 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 02:06:19 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594001179.6.0.0190304315399.issue26205@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 3f4a9fd912fc6d4f5ee2b49bfef979cc7d457848 by Miss Islington (bot) in branch '3.9':
bpo-26205: Specify the number of nested scopes (GH-21324) (GH-21341)
https://github.com/python/cpython/commit/3f4a9fd912fc6d4f5ee2b49bfef979cc7d457848


----------

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

From report at bugs.python.org  Sun Jul  5 22:07:35 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 02:07:35 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1594001255.74.0.997931440563.issue28681@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 00c09f06a4cf1e352c6ab0c9b9e6074e52f44ae1 by Miss Islington (bot) in branch '3.9':
bpo-28681: Clarify multiple function names in the tutorial (GH-21340) (GH-21343)
https://github.com/python/cpython/commit/00c09f06a4cf1e352c6ab0c9b9e6074e52f44ae1


----------

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

From report at bugs.python.org  Sun Jul  5 22:08:03 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 02:08:03 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1594001283.22.0.942442968684.issue28681@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 6790f9badda47c7aa0fe4b0b5f090d6ca0c477d5 by Miss Islington (bot) in branch '3.8':
bpo-28681: Clarify multiple function names in the tutorial (GH-21340) (GH-21344)
https://github.com/python/cpython/commit/6790f9badda47c7aa0fe4b0b5f090d6ca0c477d5


----------

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

From report at bugs.python.org  Sun Jul  5 22:48:38 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 06 Jul 2020 02:48:38 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1594003718.18.0.0809138920479.issue41165@roundup.psfhosted.org>


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


New changeset 9ce8132e1f2339cfe116dfd4795574182c2245b4 by Inada Naoki in branch 'master':
bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309)
https://github.com/python/cpython/commit/9ce8132e1f2339cfe116dfd4795574182c2245b4


----------

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

From report at bugs.python.org  Sun Jul  5 22:48:58 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 02:48:58 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1594003738.48.0.596170980629.issue41165@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +20493
pull_request: https://github.com/python/cpython/pull/21345

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

From report at bugs.python.org  Sun Jul  5 23:25:22 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 03:25:22 +0000
Subject: [issue41165] [Python 3.10] Remove APIs deprecated long enough
In-Reply-To: <1593492796.52.0.194597415316.issue41165@roundup.psfhosted.org>
Message-ID: <1594005922.55.0.590033180244.issue41165@roundup.psfhosted.org>


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


New changeset 1ce59f0421d9550762977454bda22db750aa20aa by Miss Islington (bot) in branch '3.9':
bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309)
https://github.com/python/cpython/commit/1ce59f0421d9550762977454bda22db750aa20aa


----------

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

From report at bugs.python.org  Mon Jul  6 01:26:37 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 06 Jul 2020 05:26:37 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594013197.96.0.382153151673.issue26205@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Well, then "what name is in which namespace" is relative to which function we're considering. In my example above, imagine aa has x declared, bb has y, and cc has z. Then y and z are in the same namespace when we look from the perspective of aa, but they are not in the same namespace from the perspective of bb. Even worse, cc sees z but doesn't see y. How can they be in the same namespace then?

I always thought about namespaces as mappings from names to objects, independent of perspective. Whether two names are in the same namespace, should be a question with an objective answer.

----------

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

From report at bugs.python.org  Mon Jul  6 01:31:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jul 2020 05:31:14 +0000
Subject: [issue41216] eval don't load local variable in dict and list
 comprehensions.
In-Reply-To: <1593995463.39.0.732635658928.issue41216@roundup.psfhosted.org>
Message-ID: <1594013474.51.0.234005002403.issue41216@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be a duplicate of issue5242, issue36300

----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Jul  6 02:50:18 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 06:50:18 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593973670.03.0.810025178647.issue41215@roundup.psfhosted.org>
Message-ID: <ed513abc-14d6-ee87-d7d9-03318df0c12d@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

My apologies for lack of context.

On 05/07/2020 20:27, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> Unfortunately, I am having a hard time parsing your error description because is not immediate to distinguish:
>
> - What is the error.
crash - segmentation error.
> - Where does the error happen.
During python initialization.
> - How to reproduce the error.

The error occurs during `make`

root at x066:[/data/prj/python/bpo-41215]make
??????? xlc_r -g -c? -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1
-qarch=pwr5 -O??? -I../git/bpo-41215/Include/internal -IObjects
-IInclude -IPython -I. -I../git/bpo-41215/Include -I/opt/include??
-DPy_BUILD_CORE -o Parser/pegen/pegen.o
../git/bpo-41215/Parser/pegen/pegen.c
??????? xlc_r -g -c? -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1
-qarch=pwr5 -O??? -I../git/bpo-41215/Include/internal -IObjects
-IInclude -IPython -I. -I../git/bpo-41215/Include -I/opt/include??
-DPy_BUILD_CORE? -DGITVERSION="\"`LC_ALL=C `\""? -DGITTAG="\"`LC_ALL=C
`\""? -DGITBRANCH="\"`LC_ALL=C `\""? -o Modules/getbuildinfo.o
../git/bpo-41215/Modules/getbuildinfo.c
??????? rm -f libpython3.9.a
??????? ar rcs libpython3.9.a Modules/getbuildinfo.o? Parser/acceler.o?
Parser/grammar1.o? Parser/listnode.o? Parser/node.o? Parser/parser.o?
Parser/token.o?? Parser/pegen/pegen.o? Parser/pegen/parse.o?
Parser/pegen/parse_string.o? Parser/pegen/peg_api.o Parser/myreadline.o
Parser/parsetok.o Parser/tokenizer.o? Objects/abstract.o?
Objects/accu.o? Objects/boolobject.o? Objects/bytes_methods.o?
Objects/bytearrayobject.o? Objects/bytesobject.o? Objects/call.o?
Objects/capsule.o? Objects/cellobject.o? Objects/classobject.o?
Objects/codeobject.o? Objects/complexobject.o? Objects/descrobject.o?
Objects/enumobject.o? Objects/exceptions.o?
Objects/genericaliasobject.o? Objects/genobject.o? Objects/fileobject.o?
Objects/floatobject.o? Objects/frameobject.o? Objects/funcobject.o?
Objects/interpreteridobject.o? Objects/iterobject.o?
Objects/listobject.o? Objects/longobject.o? Objects/dictobject.o?
Objects/odictobject.o? Objects/memoryobject.o? Objects/methodobject.o?
Objects/moduleobject.o? Objects/namespaceobject.o? Objects/object.o?
Objects/obmalloc.o? Objects/picklebufobject.o? Objects/rangeobject.o?
Objects/setobject.o? Objects/sliceobject.o? Objects/structseq.o?
Objects/tupleobject.o? Objects/typeobject.o? Objects/unicodeobject.o?
Objects/unicodectype.o? Objects/weakrefobject.o? Python/_warnings.o?
Python/Python-ast.o? Python/asdl.o? Python/ast.o? Python/ast_opt.o?
Python/ast_unparse.o? Python/bltinmodule.o? Python/ceval.o?
Python/codecs.o? Python/compile.o? Python/context.o?
Python/dynamic_annotations.o? Python/errors.o? Python/frozenmain.o?
Python/future.o? Python/getargs.o? Python/getcompiler.o?
Python/getcopyright.o? Python/getplatform.o? Python/getversion.o?
Python/graminit.o? Python/hamt.o? Python/import.o? Python/importdl.o?
Python/initconfig.o? Python/marshal.o? Python/modsupport.o?
Python/mysnprintf.o? Python/mystrtoul.o? Python/pathconfig.o?
Python/peephole.o? Python/preconfig.o? Python/pyarena.o?
Python/pyctype.o? Python/pyfpe.o? Python/pyhash.o? Python/pylifecycle.o?
Python/pymath.o? Python/pystate.o? Python/pythonrun.o? Python/pytime.o?
Python/bootstrap_hash.o? Python/structmember.o? Python/symtable.o?
Python/sysmodule.o? Python/thread.o? Python/traceback.o?
Python/getopt.o? Python/pystrcmp.o? Python/pystrtod.o?
Python/pystrhex.o? Python/dtoa.o? Python/formatter_unicode.o?
Python/fileutils.o? Python/dynload_shlib.o??????? Modules/config.o?
Modules/getpath.o? Modules/main.o? Modules/gcmodule.o?
Modules/posixmodule.o? Modules/errnomodule.o? Modules/pwdmodule.o?
Modules/_sre.o? Modules/_codecsmodule.o? Modules/_weakref.o?
Modules/_functoolsmodule.o? Modules/_operator.o?
Modules/_collectionsmodule.o? Modules/_abc.o? Modules/itertoolsmodule.o?
Modules/atexitmodule.o? Modules/signalmodule.o? Modules/_stat.o?
Modules/timemodule.o? Modules/_threadmodule.o? Modules/_localemodule.o?
Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o
Modules/bufferedio.o Modules/textio.o Modules/stringio.o?
Modules/faulthandler.o? Modules/_tracemalloc.o Modules/hashtable.o?
Modules/_peg_parser.o? Modules/symtablemodule.o? Modules/xxsubtype.o?
Python/frozen.o
??????? ../git/bpo-41215/Modules/makexp_aix Modules/python.exp .
libpython3.9.a;? xlc_r -g???? -Wl,-bE:Modules/python.exp -lld -o python
Programs/python.o libpython3.9.a -lintl -ldl? -lm?? -lm
???????? ./python -E -S -m sysconfig --generate-posix-vars ; if test $?
-ne 0 ; then? echo "generate-posix-vars failed" ;? rm -f
./pybuilddir.txt ;? exit 1 ;? fi
/bin/sh: 5242890 Segmentation fault(coredump)
make: 1254-004 The error code from the last command is 139.

Stop.

And can be repeated by just trying to start the executable:

root at x066:[/data/prj/python/bpo-41215]./python
Segmentation fault(coredump)

>
> Could you kindly provide more scoped information about these points so we can look into it?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jul  6 02:54:26 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 06:54:26 +0000
Subject: [issue35773] test_bdb fails on non-UTF-8 locale
In-Reply-To: <1593078570.7.0.461525749711.issue35773@roundup.psfhosted.org>
Message-ID: <8a8f14ea-0af2-4e5f-632d-e7ad68097d04@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks for getting back to this. ++1 :)

On 25/06/2020 11:49, Serhiy Storchaka wrote:
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> test_bdb fails on non-UTF-8 locale because Python executes a Python code from the corresponding "encodings" submodule. There are shortcuts for the UTF-8 codec which avoid using the Python code.
>
> ----------
> nosy: +serhiy.storchaka
> title: test_bdb fails on AIX bot (regression) -> test_bdb fails on non-UTF-8 locale
> versions: +Python 3.10, Python 3.9
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35773>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jul  6 03:20:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jul 2020 07:20:38 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594020038.8.0.301067682517.issue41208@roundup.psfhosted.org>


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

How did you get this file?

----------

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

From report at bugs.python.org  Mon Jul  6 03:43:52 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:43:52 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1594021432.01.0.922745212941.issue27154@roundup.psfhosted.org>


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

Removing 'b' and 'u', writelines([s]) and write(s) both now read as s.

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Jul  6 03:45:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:45:04 +0000
Subject: [issue26212] Python with ncurses6.0 will not load _curses module on
 Solaris 10
In-Reply-To: <1453851633.31.0.356555678785.issue26212@psf.upfronthosting.co.za>
Message-ID: <1594021504.6.0.148905105569.issue26212@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

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

From report at bugs.python.org  Mon Jul  6 03:45:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:45:49 +0000
Subject: [issue34154] Tkinter __init__ documentations sometimes missing valid
 keyword values
In-Reply-To: <1531969710.94.0.56676864532.issue34154@psf.upfronthosting.co.za>
Message-ID: <1594021549.89.0.745078277273.issue34154@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Jul  6 03:47:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:47:57 +0000
Subject: [issue34908] netrc parsing is overly strict
In-Reply-To: <1538760084.12.0.545547206417.issue34908@psf.upfronthosting.co.za>
Message-ID: <1594021677.83.0.417830939908.issue34908@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 2.7, Python 3.7

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

From report at bugs.python.org  Mon Jul  6 03:49:35 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:49:35 +0000
Subject: [issue22433] Argparse considers unknown optional arguments with
 spaces as a known positional argument
In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za>
Message-ID: <1594021775.9.0.709752979478.issue22433@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 2.7

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

From report at bugs.python.org  Mon Jul  6 03:50:09 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:50:09 +0000
Subject: [issue13554] Tkinter doesn't use higher resolution app icon
In-Reply-To: <1323308666.66.0.322569696678.issue13554@psf.upfronthosting.co.za>
Message-ID: <1594021809.54.0.304372211705.issue13554@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

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

From report at bugs.python.org  Mon Jul  6 03:56:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 07:56:12 +0000
Subject: [issue39189] Use io.DEFAULT_BUFFER_SIZE for filecmp BUFSIZE variable
In-Reply-To: <1577962528.13.0.543315983881.issue39189@roundup.psfhosted.org>
Message-ID: <1594022172.37.0.124836071964.issue39189@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Jul  6 04:00:42 2020
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 06 Jul 2020 08:00:42 +0000
Subject: [issue37363] Additional PEP578 hooks
In-Reply-To: <1561131749.05.0.996884755083.issue37363@roundup.psfhosted.org>
Message-ID: <1594022442.74.0.400794466014.issue37363@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi @Christian,

When you have time for my last question.

Thank you,

----------

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

From report at bugs.python.org  Mon Jul  6 04:07:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:07:33 +0000
Subject: [issue27578] inspect.findsource raises exception with empty
 __init__.py
In-Reply-To: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za>
Message-ID: <1594022853.39.0.159800151113.issue27578@roundup.psfhosted.org>


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

I agree that getsource raising is a bug.  I would more at the behavior and doc for getlines before I decided about that.

----------
nosy: +terry.reedy
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.9

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

From report at bugs.python.org  Mon Jul  6 04:10:51 2020
From: report at bugs.python.org (Csaba Nemes)
Date: Mon, 06 Jul 2020 08:10:51 +0000
Subject: [issue41217] Obsolete note for default asyncio event loop on Windows
Message-ID: <1594023051.16.0.859268804549.issue41217@roundup.psfhosted.org>


New submission from Csaba Nemes <waszil.waszil at gmail.com>:

In the documentation of asyncio, a Note is present in the "Running Subprocesses" section: "The default asyncio event loop on Windows does not support subprocesses", however, from 3.8 the default event loop is ProactorEventLoop on Windows, that does support subprocesses. This note should be removed.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 373076
nosy: asvetlov, docs at python, waszil, yselivanov
priority: normal
severity: normal
status: open
title: Obsolete note for default asyncio event loop on Windows
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul  6 04:16:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:16:04 +0000
Subject: [issue24670] os.chdir breaks result of os.path.abspath(__file__) and
 os.path.realpath(__file__)
In-Reply-To: <1437315993.36.0.280874267638.issue24670@psf.upfronthosting.co.za>
Message-ID: <1594023363.99.0.73393441308.issue24670@roundup.psfhosted.org>


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

I interpret Serhiy's comment as 'not a bug'.  In any case, the linked issue changed __file__ to an absolute path, and 2.7 is frozen.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24670>
_______________________________________

From report at bugs.python.org  Mon Jul  6 04:40:47 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:40:47 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1594024847.29.0.367262129239.issue11105@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With 3.9 on Windows, using Benjamin's example, I do not get the Windows equivalent of a seg fault.  However, execution stops at compile with no exception, including SystemExit.

These examples amount to limited fuzz testing of compile().  I think it should raise something like "SyntaxError: recursive ast" or even 'bad ast' if malformed non-recursive asts have the same issue.

----------
nosy: +terry.reedy
versions: +Python 3.10 -Python 2.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11105>
_______________________________________

From report at bugs.python.org  Mon Jul  6 04:41:30 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:41:30 +0000
Subject: [issue23885] urllib.quote horribly mishandles unicode as second
 parameter
In-Reply-To: <1428441015.17.0.142718858432.issue23885@psf.upfronthosting.co.za>
Message-ID: <1594024890.74.0.93466051405.issue23885@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23885>
_______________________________________

From report at bugs.python.org  Mon Jul  6 04:43:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:43:04 +0000
Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS
 X 10.9 only)
In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za>
Message-ID: <1594024984.1.0.815725910867.issue20353@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20353>
_______________________________________

From report at bugs.python.org  Mon Jul  6 04:44:34 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:44:34 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1594025074.0.0.361023302777.issue17576@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Mon Jul  6 04:47:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:47:02 +0000
Subject: [issue34689] Lib/sysconfig.py expands non-variables
In-Reply-To: <1536955893.22.0.956365154283.issue34689@psf.upfronthosting.co.za>
Message-ID: <1594025222.13.0.25717050153.issue34689@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +berker.peksag, serhiy.storchaka
versions: +Python 3.10 -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34689>
_______________________________________

From report at bugs.python.org  Mon Jul  6 04:47:40 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 08:47:40 +0000
Subject: [issue34938] Fix mimetype.init() to account for from import
In-Reply-To: <1539036789.21.0.545547206417.issue34938@psf.upfronthosting.co.za>
Message-ID: <1594025260.5.0.845460141444.issue34938@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34938>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:04:08 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 06 Jul 2020 09:04:08 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1594026248.34.0.493004127043.issue41212@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Sorry, the point I was trying to make was that, unlike UTF-8, Tcl doesn't support variable length characters and they are instead fixed at 16 bits (by default). So, while Python and UTF-8 are perfectly happy with the emoji, unless Tcl is compiled with a particular build flag it will not process the character correctly (hence why I said it was surprising that Chip showed at all). I have tested on Tcl 8.6.10 and encountered the same problem described.

A further quote (granted, also old, but I cannot find anything to suggest this behaviour has been changed):
"Tcl can (currently) only represent characters within the Basic Multilingual Plane of Unicode, so there's no way that you can even feed an U+10000 into encoding convertto :-(. Fixing that is non-trivial, since some parts of Tcl (the C library) require a representation of strings where all characters take up the same number of bytes. It is possible to compile Tcl with that "number of bytes" set to 4 (meaning 32 bits per character), but it's rather wasteful, and has been reported not entirely compatible with Tk." [https://wiki.tcl-lang.org/page/utf-8]

If I can find the build flag mentioned, I will post it here for future reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41212>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:10:59 2020
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 06 Jul 2020 09:10:59 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594026659.68.0.551926923806.issue41206@roundup.psfhosted.org>


Change by Matthias Klose <doko at debian.org>:


----------
nosy: +ivyl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:12:33 2020
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 06 Jul 2020 09:12:33 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594026753.26.0.338133234879.issue41206@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

that's a regression for the 3.8 branch, marking as a release blocker for 3.8.4.  This should be a documented change for 3.9, and probably reverted/fixed for 3.8.

----------
keywords: +3.8regression, 3.9regression
nosy: +doko, lukasz.langa
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:12:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 09:12:54 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594026774.29.0.609797971108.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 883bc638335a57a6e6a6344c2fc132c4f9a0ec42 by Hai Shi in branch 'master':
bpo-40275: Use new test.support helper submodules in tests (GH-21314)
https://github.com/python/cpython/commit/883bc638335a57a6e6a6344c2fc132c4f9a0ec42


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:15:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 09:15:11 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594026911.7.0.224531329877.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a089d21df1ea502b995d8e8a3bcc937cce030802 by Hai Shi in branch 'master':
bpo-40275: Use new test.support helper submodules in tests (GH-21315)
https://github.com/python/cpython/commit/a089d21df1ea502b995d8e8a3bcc937cce030802


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:27:21 2020
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 06 Jul 2020 09:27:21 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1594027641.96.0.315249789711.issue40204@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

please note that pinning usually is not a solution for Linux distributions.  Yes, the most wanted fix would be to fix sphinx 3.x not to break compatibility with 2.x.  Or limit 3.9 to 2.x features for now.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:31:57 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Jul 2020 09:31:57 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1594027917.95.0.546537414874.issue11105@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> With 3.9 on Windows, using Benjamin's example, I do not get the Windows equivalent of a seg fault.  However, execution stops at compile with no exception, including SystemExit.

I can still reproduce on Linux,

 $ python
Python 3.10.0a0 (heads/bpo-xxxxx:f2947e354c, May 21 2020, 18:54:57) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> e = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> e.operand = e
>>> compile(ast.Expression(e), "<test>", "eval")
[1]    15320 segmentation fault (core dumped)  python


> These examples amount to limited fuzz testing of compile().  I think it should raise something like "SyntaxError: recursive ast" or even 'bad ast' if malformed non-recursive asts have the same issue.

I dont think it would be easy to locate such errors before they happen, instead I propose (actually already proposed in PR 20594) to add recursion guards to places where this might happen. This can prevent crashes on both direct and indirect cycles

>>> import ast
>>> e = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> e.operand = e
>>> compile(ast.Expression(e), "<test>", "eval")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RecursionError: maximum recursion depth exceeded while traversing 'expr' node
>>> e = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> f = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> e.operand = f
>>> f.operand = e
>>> compile(ast.Expression(e), "<test>", "eval")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RecursionError: maximum recursion depth exceeded while traversing 'expr' node

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11105>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:40:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 09:40:20 +0000
Subject: [issue28681] Clarify multiple function names in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1594028420.31.0.644387622178.issue28681@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28681>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:49:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 09:49:06 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594028946.64.0.183716599986.issue26205@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since you ask, here is a extended summary of namespaces. There is one built-in namespace.  There is one global namespace for each module, which is also the local namespace for top level code in that module.  There is one local namespace for each class and function.  There is one nonlocal namespace for each nested function.  "At any time during execution" (the beginning of the doc sentence targeted by this issue), there are 3 or maybe 4 namespaces accessible with simple undotted names. 

Module global and class local namespaces, including nested classes, are accessible from without the object with dotted names.  There are rules for class and method code about access to superclass namespaces.  Function locals are not necessarily accessible with standard python code, but at least in cpython, local names can be accessed via code objects.  Default parameter values and current nonlocal values, when set, can be accessed via function objects.  Dotted names are discussed elsewhere in the tutorial, while function and code object introspection is out of scope there.  (And off topic for this issue ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26205>
_______________________________________

From report at bugs.python.org  Mon Jul  6 05:49:54 2020
From: report at bugs.python.org (Ma Lin)
Date: Mon, 06 Jul 2020 09:49:54 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594028994.2.0.810901198991.issue41210@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

The docs[1] said:

    Compression filters:
            FILTER_LZMA1 (for use with FORMAT_ALONE)
            FILTER_LZMA2 (for use with FORMAT_XZ and FORMAT_RAW)

But your code uses a combination of `FILTER_LZMA1` and `FORMAT_RAW`, is this ok?

[1] https://docs.python.org/3/library/lzma.html#specifying-custom-filter-chains

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Mon Jul  6 06:03:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jul 2020 10:03:00 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594029780.23.0.307592926792.issue26205@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Besides the sentence now revised, the initial post referenced confusion with 'middle scope' in "If a name is declared global, then all references and assignments go directly to the middle scope containing the module's global names."

This has not been directly discussed that I could find, but it seems inappropriate both at toplevel, where globals = locals, and in nested functions, where nonlocals are also 'middle'.  Maybe replace "the middle scope containing the module's global names" with "the module's global namespace".  The rest of this paragraph and the next could be reviewed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26205>
_______________________________________

From report at bugs.python.org  Mon Jul  6 06:09:58 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 06 Jul 2020 10:09:58 +0000
Subject: [issue41018] warning: 'Tk_MainWindow' is deprecated: first deprecated
In-Reply-To: <1593981567.9.0.286119727843.issue41018@roundup.psfhosted.org>
Message-ID: <1594030198.57.0.646007085341.issue41018@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The deprecation warnings are a specific "feature" of the copy of Tcl/Tk shipped by Apple, and do not reflect the status of this API upstream.

The correct fix is to either ignore these warnings when building, or better to use a different install of Tcl/Tk (later versions are substantially better, which is why the Python.org installers for macOS ship with a copy of Tcl/Tk).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41018>
_______________________________________

From report at bugs.python.org  Mon Jul  6 06:17:16 2020
From: report at bugs.python.org (Ben Griffin)
Date: Mon, 06 Jul 2020 10:17:16 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1594030636.54.0.772682873727.issue41212@roundup.psfhosted.org>


Ben Griffin <ben at redsnapper.net> added the comment:

Wow, well if you are right, then TCL/TK is a showstopper for us, and we will have to consider an alternative to tkinter. 

Frankly, I am aghast that any active software would be limited to fixed width characters.

We moved our languages over to multiwidth (utf-8) back in 2003: most of the changes were restricted to a handful of string functions (strcut, strlen, etc.). Compiling TCL to use 4 byte chars isn?t really a solution either.

What confuses me is that there are several people on SO who are saying ?works for me?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41212>
_______________________________________

From report at bugs.python.org  Mon Jul  6 06:41:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 10:41:40 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594032100.27.0.200530257198.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I tried compiling Python 3.10 with XLC on AIX and I get a crash in a different place that does not involve the parser:

_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x300b5190, throwflag = 0), line 427 in "object.h"
_PyEval_EvalCode(tstate = 0x10024050, _co = 0x30048238, globals = 0x2ff1b440, locals = 0x20043d14, args = 0x10024654, argcount = 806053032, kwnames = 0x2ff1b450, kwargs = 0x300a8b20, kwcount = 0, kwstep = 2,
defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x10030d78, globals = 0x300aca40, locals = 0x300a9808, args = (nil), argcount = 0, kwnames = 0x300a0ad0, kwargs = 0x2ff1b4e0, kwcount = 805747592, kwstep = 2, defs = (nil), defc
ount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4397 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x3009c9d4, globals = 0x104f4bd8, locals = 0x20044f40, args = (nil), argcount = 2, kws = (nil), kwcount = 804369808, defs = 0x300847c8, defcount = 0, kwdefs = (nil), closure = (nil)),
line 4415 in "ceval.c"
builtin___build_class__(self = 0x10121d9c, args = 0x300a8b20, nargs = 804369888, kwnames = 0x20043d14), line 222 in "bltinmodule.c"
cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x1022a424, args = 0x3009d090, nargsf = 804370000, kwnames = 0x20043d14), line 440 in "methodobject.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x300ac900, throwflag = 0), line 114 in "abstract.h"
_PyEval_EvalCode(tstate = 0x3009c9d4, _co = 0x104f4bd8, globals = 0x20044f40, locals = 0x300887d8, args = 0x30088774, argcount = 84, kwnames = 0x30088784, kwargs = 0x00000006, kwcount = 0, kwstep = 2, defs =
(nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x00000002, globals = 0x200764e0, locals = (nil), args = 0x30041e68, argcount = 805670664, kwnames = 0x300a8b20, kwargs = 0x2ff1bda0, kwcount = 537148692, kwstep = 2, defs = (ni
l), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4397 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x100e6a6c, globals = 0x00000060, locals = 0x2ff1bdf0, args = 0x20000440, argcount = 536901064, kws = 0x20007820, kwcount = 804371984, defs = 0x20043d14, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x1012ad08, globals = 0x10504de8, locals = 0x300b82f8), line 857 in "ceval.c"
builtin_exec_impl(module = 0x30066704, source = 0x30089a30, globals = 0x30041e68, locals = 0xcfd41162), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x3006686c, args = 0x300734d8, nargs = 0), line 371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x300734d8, args = 0x200764e0, nargsf = 804372448, kwnames = (nil)), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0x3005dad8, tuple = 0xffffffff, kwargs = 0x2ff1bff0), line 249 in "call.c"
_PyObject_Call(tstate = 0x101185e0, callable = 0x30058ed8, args = 0x2ff1c030, kwargs = (nil)), line 265 in "call.c"
unnamed block in do_call_core(tstate = 0x100bf40c, func = 0x30089a30, callargs = (nil), kwdict = (nil)), line 5142 in "ceval.c"
unnamed block in do_call_core(tstate = 0x100bf40c, func = 0x30089a30, callargs = (nil), kwdict = (nil)), line 5142 in "ceval.c"
do_call_core(tstate = 0x100bf40c, func = 0x30089a30, callargs = (nil), kwdict = (nil)), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3009c8a0, throwflag = 0), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x00000002, _co = 0x200746f0, globals = 0x300a97d8, locals = 0x200764e0, args = 0x200764e0, argcount = 804375636, kwnames = 0x200486e0, kwargs = 0xde5cc1d8, kwcount = 0, kwstep = 1,
defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001aba8, qualname = 0x3001aba8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x0000000e, stack = 0x20007820, nargsf = 804374496, kwnames = 0x84882224), line 410 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3006ba40, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0x00000002, co = (nil), args = (nil), nargs = 805657496, globals = 0x2ff1d350), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0x00000002, co = (nil), args = (nil), nargs = 805657496, globals = 0x2ff1d350), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005d390, stack = 0x300586b8, nargsf = 536911832, kwnames = 0x30049178), line 378 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x300ad1b0, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0x00000002, co = 0x200746f0, args = 0x300a97d8, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0x00000002, co = 0x200746f0, args = 0x300a97d8, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3007ce88, stack = 0x300a4468, nargsf = 804378112, kwnames = 0x20000440), line 378 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3006ab20, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0x00000002, co = 0x200746f0, args = 0x300a97d8, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0x00000002, co = 0x200746f0, args = 0x300a97d8, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x1015971c, stack = (nil), nargsf = 804379888, kwnames = 0x20043d14), line 378 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x300ad030, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0x101524f4, co = 0x30002068, args = 0x2ff1e350, nargs = 537148692, globals = 0x300a9b08), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0x101524f4, co = 0x30002068, args = 0x2ff1e350, nargs = 537148692, globals = 0x300a9b08), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x100be45c, stack = 0x0000000a, nargsf = 0, kwnames = 0x20043d14), line 378 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = (nil), name = 0x20010dc0, ... = 0x300a97d8, 0x3004b450, 0x0, 0x1010101, 0x4f004942, 0x800000), line 882 in "call.c"
import_find_and_load(tstate = 0x30087df0, abs_name = 0x200764e0), line 1765 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x300062f8, globals = 0x300a8618, locals = 0x2ff1e5c0, fromlist = 0x300aa280, level = 269622228), line 1866 in "import.c"
import_name(tstate = 0x1022a424, f = 0x00000005, name = (nil), fromlist = 0x20043d14, level = (nil)), line 5234 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x30087df0, throwflag = 0), line 3120 in "ceval.c"
_PyEval_EvalCode(tstate = 0x30066704, _co = 0x104f4bd8, globals = 0x20044f40, locals = 0x3008873c, args = 0x300886cc, argcount = 96, kwnames = 0x300886dc, kwargs = 0x00000008, kwcount = 0, kwstep = 2, defs =
(nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x00000002, globals = 0x200764e0, locals = (nil), args = 0x30041e68, argcount = 805670664, kwnames = 0x300a8618, kwargs = 0x2ff1ed80, kwcount = 537148692, kwstep = 2, defs = (ni
l), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4397 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x100e6a6c, globals = 0x20007820, locals = 0x2ff1edd0, args = 0x88484224, argcount = 269815832, kws = 0x3003e770, kwcount = 2, defs = 0x00000001, defcount = 0, kwdefs = (nil), closure
= (nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x101539b4, globals = 0x10504de8, locals = 0x300aa280), line 857 in "ceval.c"
builtin_exec_impl(module = 0xdeadbeef, source = 0x30089a30, globals = 0x300a1390, locals = (nil)), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x3006e228, args = 0x300734d8, nargs = 0), line 371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x300734d8, args = 0x200764e0, nargsf = 804384704, kwnames = 0xdeadbeef), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0x3005dad8, tuple = 0xffffffff, kwargs = 0x2ff1efd0), line 249 in "call.c"
_PyObject_Call(tstate = 0x101185e0, callable = 0x30058ed8, args = 0x2ff1f010, kwargs = 0xdeadbeef), line 265 in "call.c"
unnamed block in do_call_core(tstate = 0x100bf40c, func = 0x30089a30, callargs = (nil), kwdict = 0xdeadbeef), line 5142 in "ceval.c"
unnamed block in do_call_core(tstate = 0x100bf40c, func = 0x30089a30, callargs = (nil), kwdict = 0xdeadbeef), line 5142 in "ceval.c"
do_call_core(tstate = 0x100bf40c, func = 0x30089a30, callargs = (nil), kwdict = 0xdeadbeef), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x300665d0, throwflag = 0), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0xdeadbeef, _co = 0x200746f0, globals = 0x300a6868, locals = 0x200764e0, args = 0x200764e0, argcount = 804387892, kwnames = 0x200486e0, kwargs = 0xde5cc1d8, kwcount = 0, kwstep = 1,
defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001aba8, qualname = 0x3001aba8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3009a848, stack = 0x2ff22008, nargsf = 20, kwnames = 0x104f4bd8), line 410 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3006b760, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0xdeadbeef, co = (nil), args = (nil), nargs = 805657496, globals = 0x2ff20330), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0xdeadbeef, co = (nil), args = (nil), nargs = 805657496, globals = 0x2ff20330), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005d390, stack = 0x300586b8, nargsf = 536911832, kwnames = 0x30049178), line 378 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3006c930, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0xdeadbeef, co = 0x200746f0, args = 0x300a6868, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0xdeadbeef, co = 0x200746f0, args = 0x300a6868, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3004df58, stack = 0x30092968, nargsf = 804390352, kwnames = 0x30038988), line 378 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3006a350, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0xdeadbeef, co = 0x200746f0, args = 0x300a6868, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0xdeadbeef, co = 0x200746f0, args = 0x300a6868, nargs = 537355488, globals = 0x200764e0), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x1002a464, stack = (nil), nargsf = 804392224, kwnames = 0x20043d14), line 378 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200764e0, f = 0x3006c7b0, throwflag = 0), line 114 in "abstract.h"
unnamed block in function_code_fastcall(tstate = 0x101524f4, co = (nil), args = 0x20003018, nargs = 537148692, globals = 0x300a6898), line 40 in "pycore_ceval.h"
function_code_fastcall(tstate = 0x101524f4, co = (nil), args = 0x20003018, nargs = 537148692, globals = 0x300a6898), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x100be45c, stack = 0x0000000a, nargsf = 0, kwnames = 0x20043d14), line 378 in "call.c"
object_vacall(tstate = 0x100e2454, base = 0x200764e0, callable = 0x200746f0, vargs = (nil)), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = 0x30064880, name = 0x20010dc0, ... = 0x300a6868, 0x3004b450, 0x0, 0x1010101, 0x4f004942, 0x800000), line 882 in "call.c"
import_find_and_load(tstate = (nil), abs_name = 0x3009a7a0), line 1765 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x3009a810, globals = 0x00000005, locals = 0x2ff215a0, fromlist = 0x200374d8, level = 804394368), line 1866 in "import.c"
builtin___import__(self = 0x1012a334, args = 0x00000002, kwds = 0x2ff21620), line 280 in "bltinmodule.c"
cfunction_call(func = (nil), args = 0x200764e0, kwargs = (nil)), line 556 in "methodobject.c"
_PyObject_MakeTpCall(tstate = 0x100d2a3c, callable = 0x3004b3f0, args = (nil), nargs = 537148692, keywords = (nil)), line 191 in "call.c"
_PyObject_CallFunctionVa(tstate = 0x00000001, callable = 0x2ff22008, format = "/\362!I/\362!e/\362!v/\362"Z/\362"p/\362"~/\362$^A/\362$^\/\362$0/\362$G/\362%h/\362%|/\362%\234/\362%\314/\362&|/\362&\232/\362&
\272/\362&\316/\362&\347/\362'$/\362'5/\362'a/\362'\267/\362'\306/\362'\333/\362(^Y/\362(4/\362(X/\362(c/\362(\213/\362(\235/\362(\274/\362(\311/\362(\350/\362*f/\362*t/\362*\215/\362*\235/\362*\274/\362*\323
/\362*\375/\362+^H/\362++/\362+A/\362+a/\362+h/\362+r/\362+}/\362+\243/\362+\320/\362+\375/\362,^I/\362,6/\362,>/\362,S/\362,d/\362,o/\362,\200/\362,\213/\362-\206/\362-\262/\362-\305/\362-\327/\362.^I/\362.^
Z/\362.'/\362.8/\362.V/\362.]/\362.u/\362.\211/\362.\230/\362.\355/\362.\370/\362/2", va = "", is_size_t = -559038737), line 65592 in "abstract.h"
PyObject_CallFunction(callable = 0x1048af4c, format = "OOOOi", ... = 0x300a6868, 0x3009a810, 0x3009a810, 0x30086508, 0x0, 0x0), line 564 in "call.c"
PyImport_Import(module_name = 0xdeadbeef), line 2067 in "import.c"
PyImport_ImportModule(name = "\201\201"), line 1482 in "import.c"
_PyCodecRegistry_Init(), line 1547 in "codecs.c"
_PyCodec_Forget(encoding = "\177\200"), line 128 in "codecs.c"
init_stdio_encoding(tstate = 0x00000008), line 15996 in "unicodeobject.c"
init_fs_encoding(tstate = 0x200764e0), line 16110 in "unicodeobject.c"
_PyUnicode_InitEncodings(tstate = 0x20000440), line 16126 in "unicodeobject.c"
init_interp_main(tstate = 0x00000001), line 1016 in "pylifecycle.c"
pyinit_main(tstate = (nil)), line 1107 in "pylifecycle.c"
Py_InitializeFromConfig(config = (nil)), line 1151 in "pylifecycle.c"
pymain_init(args = 0xf0a26210), line 66 in "main.c"
pymain_main(args = 0x00000001), line 694 in "main.c"
Py_BytesMain(argc = -559038737, argv = 0xdeadbeef), line 727 in "main.c"
python.main(argc = 0, argv = (nil)), line 15 in "python.c"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 06:47:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 10:47:33 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594032453.34.0.102187295104.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

If I check out commit c5fc15685202cda73f7c3f5c6f299b0945f58508 I get a crash, but not on master or 3.9 HEAD. So whatever error happens with XLC in the PEG parser c5fc15685202cda73f7c3f5c6f299b0945f58508 seems that is already solved.

Could you confirm that you get a a different crash (different backtrace) in master, Michael?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:00:20 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Jul 2020 11:00:20 +0000
Subject: [issue18080] setting CC no longer overrides default linker for
 extension module builds on OS X
In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za>
Message-ID: <1594033220.56.0.465733675975.issue18080@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> Would you like me to file a separate bug for this issue? Or apply that patch? Or something else?

OK, if I understand correctly, the problem you describe does not affect cPython because cPython's Distutils does not use get_config_vars(), only get_config_var(); but other implementation's ports of Distutils may have diverged to use get_config_vars and so the test may fail when running under those implementations using setuptools with its newly cloned version of cPython Distutils.  If that is the case, I think it's fine to backport the fix to cPython tests in the interest of minimizing differences. Since it is minor and not really user visible, if you're willing to do so, I'm OK with a PR under this bpo and I don't think a NEWS blurb is necessary.  Thanks for bringing it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18080>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:10:49 2020
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Jul 2020 11:10:49 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1594033849.92.0.586558979704.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

As noted in the first message of this thread, the sqrt-max-prec feature
(requested by Mark and Tim) was already in 3.9 long before the beta
freeze.

I'm not sure why this is not clear from the original message.

That fix is safe for Python, but not for the standalone libmpdec.


The standalone libmpdec had to be updated, and was updated according
to the Debian-friendly way requested by Matthias himself.


Note that a pinning issue in another area of Python has surfaced in
the last 24 hours.  I wonder if the reaction will be a strong as here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40874>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:18:13 2020
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Jul 2020 11:18:13 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1594034293.98.0.851314643324.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> The standalone libmpdec had to be updated, and was updated according
to the Debian-friendly way requested by Matthias himself.

Not updated, of course the sqrt-max-prec *had never been* in
the standalone libmpdec, it is new in 2.5.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40874>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:22:11 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 06 Jul 2020 11:22:11 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1594034531.55.0.61408345141.issue37207@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset b4a9263708cc67c98c4d53b16933f6e5dd07990f by Dong-hee Na in branch 'master':
bpo-37207: Update whatsnews for 3.9 (GH-21337)
https://github.com/python/cpython/commit/b4a9263708cc67c98c4d53b16933f6e5dd07990f


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:22:31 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 11:22:31 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1594034551.1.0.0832936401342.issue37207@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20494
pull_request: https://github.com/python/cpython/pull/21347

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:28:25 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 06 Jul 2020 11:28:25 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1594034905.74.0.684711913291.issue40874@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy:  -christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40874>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:31:49 2020
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Jul 2020 11:31:49 +0000
Subject: [issue40874] Update to libmpdec-2.5.0
In-Reply-To: <1591374563.33.0.374271364023.issue40874@roundup.psfhosted.org>
Message-ID: <1594035109.63.0.640446616292.issue40874@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

More than that, I had *promised* Matthias privately to release a
new libmpdec for the sqrt-max-prec feature a couple of months ago.

I request that further packaging issues will be dealt with primarily
by Matthias and myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40874>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:43:29 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 11:43:29 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594035809.91.0.611033123391.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, I have investigated more and it seems that XLC is miscompiling the keyword list. For instance, if you add:

index 9d3ac575df..70d431e6be 100644
--- a/Parser/pegen/parse.c
+++ b/Parser/pegen/parse.c
@@ -1,6 +1,6 @@
-// @generated by pegen.py from ./Grammar/python.gram
 #include "pegen.h"

+// @generated by pegen.py from ./Grammar/python.gram
 #if defined(Py_DEBUG) && defined(Py_BUILD_CORE)
 extern int Py_DebugFlag;
 #define D(x) if (Py_DebugFlag) x;
@@ -24735,7 +24735,12 @@ _PyPegen_parse(Parser *p)
     // Initialize keywords
     p->keywords = reserved_keywords;
     p->n_keyword_lists = n_keyword_lists;
-
+    for (int s=0; s<p->n_keyword_lists;s++) {
+        KeywordToken *kk = p->keywords[s];
+        if (kk) {
+            printf("--> %i %.*s\n", s,s, kk->str);
+        }
+    }
     // Run parser
     void *result = NULL;
     if (p->start_rule == Py_file_input) {


Before crashing, this will print the following:

--> 2 if
--> 3 del
--> 4 pass
--> 5 raise
--> 6 return
--> 7 finally
--> 8
--> 14 __peg_parser__
Segmentation fault (core dumped)

Notice that the entry for size 8 is missing. I don't understand why is missing because the data is static and there is an entry there:

static KeywordToken *reserved_keywords[] = {
    NULL,
    NULL,
    (KeywordToken[]) {
        {"if", 510},
        {"in", 518},
        {"as", 520},
        {"is", 527},
        {"or", 532},
        {NULL, -1},
    },
    (KeywordToken[]) {
        {"del", 503},
        {"try", 511},
        {"for", 517},
        {"def", 523},
        {"not", 526},
        {"and", 533},
        {NULL, -1},
    },
    (KeywordToken[]) {
        {"pass", 502},
        {"from", 514},
        {"elif", 515},
        {"else", 516},
        {"with", 519},
        {"True", 528},
        {"None", 530},
        {NULL, -1},
    },
    (KeywordToken[]) {
        {"raise", 501},
        {"yield", 504},
        {"break", 506},
        {"while", 512},
        {"class", 524},
        {"False", 529},
        {NULL, -1},
    },
    (KeywordToken[]) {
        {"return", 500},
        {"assert", 505},
        {"global", 508},
        {"import", 513},
        {"except", 521},
        {"lambda", 525},
        {NULL, -1},
    },
    (KeywordToken[]) {
        {"finally", 522},
        {NULL, -1},
    },
    (KeywordToken[]) {
        {"continue", 507},
        {"nonlocal", 509},
        {NULL, -1},
    },
    NULL,
    NULL,
    NULL,
    NULL,
    NULL,
    (KeywordToken[]) {
        {"__peg_parser__", 531},
        {NULL, -1},
    },
};

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:48:12 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 11:48:12 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594036092.61.0.699001079141.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, this is definitively something going on with XLC. This patch solves the segfault:

diff --git a/Parser/pegen/parse.c b/Parser/pegen/parse.c
index 9d3ac575df..e5511bf815 100644
--- a/Parser/pegen/parse.c
+++ b/Parser/pegen/parse.c
@@ -1,6 +1,6 @@
-// @generated by pegen.py from ./Grammar/python.gram
-#include "pegen.h"

+#include "pegen.h"
+// @generated by pegen.py from ./Grammar/python.gram
 #if defined(Py_DEBUG) && defined(Py_BUILD_CORE)
 extern int Py_DebugFlag;
 #define D(x) if (Py_DebugFlag) x;
@@ -9,8 +9,8 @@ extern int Py_DebugFlag;
 #endif
 static const int n_keyword_lists = 15;
 static KeywordToken *reserved_keywords[] = {
-    NULL,
-    NULL,
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
     (KeywordToken[]) {
         {"if", 510},
         {"in", 518},
@@ -65,11 +65,11 @@ static KeywordToken *reserved_keywords[] = {
         {"nonlocal", 509},
         {NULL, -1},
     },
-    NULL,
-    NULL,
-    NULL,
-    NULL,
-    NULL,
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
     (KeywordToken[]) {
         {"__peg_parser__", 531},
         {NULL, -1},
@@ -24735,7 +24735,6 @@ _PyPegen_parse(Parser *p)
     // Initialize keywords
     p->keywords = reserved_keywords;
     p->n_keyword_lists = n_keyword_lists;
-
     // Run parser
     void *result = NULL;
     if (p->start_rule == Py_file_input) {

Is a C99 violation to have NULL elements in this array? (Michael, could you also double check that this patch solves it for you?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:54:13 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 06 Jul 2020 11:54:13 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594036453.29.0.0270983134383.issue41206@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Good catch!

No need to revert anything. The raised ValueError is a relatively simple thing to fix. xtreak, mind making a follow-up PR to restore behavior with no \n characters?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:57:16 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 06 Jul 2020 11:57:16 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594036636.51.0.196596777788.issue41207@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Good catch! The unification change is 3.10 only but I'm totally fine accepting the _compile fix in Python 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:59:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jul 2020 11:59:09 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594036749.18.0.750144868932.issue41206@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sure, I guess the fix would be to check for lines to be non-empty before doing a call to max and also convert the report as a test case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:59:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 11:59:21 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594036761.79.0.103482312275.issue41208@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

According to the Python Security Model, this issue is not security vulnerability:
(*) https://python-security.readthedocs.io/security.html#python-security-model

The marshal is not intended to be used to load untrusted code. That's why its documentation contains the red warning:
"The marshal module is not intended to be secure against erroneous or maliciously constructed data. Never unmarshal data received from an untrusted or unauthenticated source."
https://docs.python.org/dev/library/marshal.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:02:15 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Mon, 06 Jul 2020 12:02:15 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594036935.84.0.991686782477.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

By using our proprietary fuzzer. I'm a cybersecurity researcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:02:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 12:02:40 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594036960.27.0.916067872933.issue41207@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Programs trapping CompileError but not FileNotFoundError will crash where once they had error handling.

Do you mean mean that spawn() of distutils.spawn should catch FileNotFoundError and raise a CompilerError instead?

It seems like before my commit 1ec63b62035e73111e204a0e03b83503e1c58f2e, any OSError was catched and replaced with DistutilsExecError, not only FileNotFoundError.

Do you want to propose a fix?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:02:56 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Mon, 06 Jul 2020 12:02:56 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594036976.88.0.39383944285.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

What about patching that as a crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:04:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 12:04:22 +0000
Subject: [issue36302] distutils creates unreproducible .so files
In-Reply-To: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org>
Message-ID: <1594037062.67.0.930044797702.issue36302@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> An unfortunate side effect of this change is that changes the build order even if the source list order is relevant. 

That sounds like a new feature. I don't think that it was supported previously. Or maybe it was more an implementation detail.

Please open a new issue if you would like to add the ability to specify in which order source files must be compiled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36302>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:05:29 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 12:05:29 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594037129.79.0.483353676195.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is enough to reproduce the problem:

#include <stdio.h>

typedef struct {
    char *str;
    int type;
} KeywordToken;

static KeywordToken *the_array[] = {
   NULL,
   NULL,
   (KeywordToken[]) {
        {"if", 510},
        {"in", 518},
        {"as", 520},
        {"is", 527},
        {"or", 532},
        {NULL, -1},
   },
   NULL,
   NULL,
    (KeywordToken[]) {
        {"del11", 503},
        {"try22", 511},
        {NULL, -1},
    },
    NULL
};


int main() {
   for (int s=0; s<7;s++) {
      KeywordToken *tok = the_array[s];
      printf("--> %i %.*s\n", s,s, tok->str);
   }
   return 0;
}
[cpython (3.9)]$ xlc check_bad.c -o check_bad
[cpython (3.9)]$ ./check_bad
--> 0
--> 1
Segmentation fault (core dumped)


But if you change it to:

#include <stdio.h>

typedef struct {
    char *str;
    int type;
} KeywordToken;

static KeywordToken *the_array[] = {
     (KeywordToken[]) {{NULL, -1}},
     (KeywordToken[]) {{NULL, -1}},
    (KeywordToken[]) {
        {"if", 510},
        {"in", 518},
        {"as", 520},
        {"is", 527},
        {"or", 532},
        {NULL, -1},
    },
    (KeywordToken[]) {{NULL, -1}},
    (KeywordToken[]) {{NULL, -1}},
    (KeywordToken[]) {
        {"del11", 503},
        {"try22", 511},
        {NULL, -1},
    },
    (KeywordToken[]) {{NULL, -1}},
};


int main() {
   for (int s=0; s<7;s++) {
      KeywordToken *tok = the_array[s];
      printf("--> %i %.*s\n", s,s, tok->str);
   }
   return 0;
}

[cpython (3.9)]$ xlc check.c -o check
[cpython (3.9)]$ ./check
--> 0
--> 1
--> 2 if
--> 3
--> 4
--> 5 del11
--> 6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:06:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 12:06:02 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594037162.29.0.693776383254.issue41208@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python doesn't implement any protection against invalid PYC files to avoid any performance overhead at runtime. Maybe we can close this issue as WONTFIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:30:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jul 2020 12:30:04 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594038604.48.0.361837816243.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset deb016224cc506503fb05e821a60158c83918ed4 by Hai Shi in branch 'master':
bpo-40275: Use new test.support helper submodules in tests (GH-21317)
https://github.com/python/cpython/commit/deb016224cc506503fb05e821a60158c83918ed4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:32:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jul 2020 12:32:21 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594038741.82.0.0485125345546.issue41206@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There is a behavior change with my fix. 7bit is returned for Content-Transfer-Encoding before commit and skipping the heuristic if line is empty to avoid ValueError will return quoted-printable for Content-Transfer-Encoding. This is a behavior change even if the ValueError is fixed. I would like to confirm which is the correct behavior and to be documented appropriately.

Test Case in test_contentmanager.py : 

    def test_set_text_plain_empty_content_heuristics(self):
        m = self._make_message()
        content = ""
        raw_data_manager.set_content(m, content)
        self.assertEqual(str(m), textwrap.dedent("""\                             
            Content-Type: text/plain; charset="utf-8"                             
            Content-Transfer-Encoding: quoted-printable                           
                                                                                  
                                                                                  
            """))
        self.assertEqual(m.get_payload(decode=True).decode('utf-8'), "\n")
        self.assertEqual(m.get_content(), "\n")

----------
nosy: +maxking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:34:00 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 12:34:00 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594038840.99.0.284905609445.issue41215@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373107

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:35:10 2020
From: report at bugs.python.org (daniel hahler)
Date: Mon, 06 Jul 2020 12:35:10 +0000
Subject: [issue9348] Calling argparse's add_argument with the wrong number of
 metavars causes delayed error message
In-Reply-To: <1279892056.3.0.745674136702.issue9348@psf.upfronthosting.co.za>
Message-ID: <1594038910.05.0.756311868867.issue9348@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

This adds overhead, since it creates a formatter and uses it for formatting only for validation purposes.

I think it is better to only have the error when the formatter is actually used (i.e. the help is displayed - which is not the typical use case, and it should be optimized for not displaying the help (i.e. only parsing args)).
The error could be more specific than before/initially though, of course.

----------
nosy: +blueyed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9348>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:37:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 12:37:20 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594039040.95.0.662013019583.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is enough to reproduce the problem:

#include <stdio.h>

typedef struct {
    char *str;
    int type;
} KeywordToken;

static KeywordToken *the_array[] = {
   NULL,
   NULL,
   (KeywordToken[]) {
        {"if", 510},
        {"in", 518},
        {"as", 520},
        {"is", 527},
        {"or", 532},
        {NULL, -1},
   },
   NULL,
   NULL,
    (KeywordToken[]) {
        {"del11", 503},
        {"try22", 511},
        {NULL, -1},
    },
    NULL
};


int main() {
   for (int s=0; s<7;s++) {
      KeywordToken *tok = the_array[s];
      printf("--> %i\n",s);
      if (tok == NULL) {
         continue;
      }
      printf("--> %i %.*s\n", s,s, tok->str);
   }
   return 0;
}

[cpython (3.9)]$ xlc check_bad.c -o check_bad
[cpython (3.9)]$ ./check_bad
--> 0
--> 1
--> 2
Segmentation fault (core dumped)


But if you change it to:

#include <stdio.h>

typedef struct {
    char *str;
    int type;
} KeywordToken;

static KeywordToken *the_array[] = {
     (KeywordToken[]) {{NULL, -1}},
     (KeywordToken[]) {{NULL, -1}},
    (KeywordToken[]) {
        {"if", 510},
        {"in", 518},
        {"as", 520},
        {"is", 527},
        {"or", 532},
        {NULL, -1},
    },
    (KeywordToken[]) {{NULL, -1}},
    (KeywordToken[]) {{NULL, -1}},
    (KeywordToken[]) {
        {"del11", 503},
        {"try22", 511},
        {NULL, -1},
    },
    (KeywordToken[]) {{NULL, -1}},
};


int main() {
   for (int s=0; s<7;s++) {
      KeywordToken *tok = the_array[s];
      if (tok == NULL) {
         continue;
      }
      printf("--> %i %.*s\n", s,s, tok->str);
   }
   return 0;
}

[cpython (3.9)]$ xlc check.c -o check
[cpython (3.9)]$ ./check
--> 0
--> 1
--> 2 if
--> 3
--> 4
--> 5 del11
--> 6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:41:31 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 06 Jul 2020 12:41:31 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594039291.87.0.696580827323.issue41206@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:51:13 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 06 Jul 2020 12:51:13 +0000
Subject: [issue41216] eval don't load local variable in dict and list
 comprehensions.
In-Reply-To: <1593995463.39.0.732635658928.issue41216@roundup.psfhosted.org>
Message-ID: <1594039873.7.0.229563541474.issue41216@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Agreed that this is a duplicate, so I'm closing it.

----------
nosy: +eric.smith
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> eval() function in List Comprehension doesn't work

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41216>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:56:46 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jul 2020 12:56:46 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594040206.21.0.23402235601.issue41206@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +20495
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21349

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 08:59:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 06 Jul 2020 12:59:40 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1594040380.04.0.771108149163.issue37207@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +20496
pull_request: https://github.com/python/cpython/pull/21350

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 09:05:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jul 2020 13:05:58 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594040758.73.0.580311719129.issue41206@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

?ukasz, There is already a PR open for this from May linking to original issue at https://github.com/python/cpython/pull/20542 . I missed it during triaging this issue. I guess someone needs to approve that PR and merge it to master to backport to 3.9 and 3.8 to fix the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Mon Jul  6 09:32:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 06 Jul 2020 13:32:13 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1594042333.15.0.939076573464.issue37207@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 97558d6b08a656eae209d49b206f703cee0359a2 by Dong-hee Na in branch '3.9':
[3.9] bpo-37207: Update whatsnews for 3.9 (GH-21337)
https://github.com/python/cpython/commit/97558d6b08a656eae209d49b206f703cee0359a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 09:58:32 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 06 Jul 2020 13:58:32 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594043912.1.0.136714629459.issue41208@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Python's thread model is:
If an attacker can create a malicious PYC file and feed it to a Python process, then they already have full code execution privileges. There is no need to exploit a segfault. Because the marshal module should only be used for PYC files, they can straight out execute any Python code at import time. That's much simpler and works on all operating systems.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 09:59:25 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 06 Jul 2020 13:59:25 +0000
Subject: [issue36302] distutils creates unreproducible .so files
In-Reply-To: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org>
Message-ID: <1594043965.36.0.799191990997.issue36302@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That's the problem with any change to distutils, the API is unclear and that causes any change to be potentially breaking for existing users. That's why distutils has been mostly stagnant for years.

I have no particular wish w.r.t. changing behaviour, I've a local workaround for now and am hoping someone will write a tool similar to flit for packages that include extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36302>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:09:10 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Mon, 06 Jul 2020 14:09:10 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594044550.27.0.161843554027.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

I thought it's like Pickle. Then if we find an exploitable segfault just in Pickle, you would count it as a threat?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:29:02 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 06 Jul 2020 14:29:02 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1594045742.27.0.723502141441.issue41177@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> If it is not goal

I don't have a goal to make these part of a documented API. OP, can you share a use case where you need to iterate over these internal structures?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:30:15 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 14:30:15 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594039040.95.0.662013019583.issue41215@roundup.psfhosted.org>
Message-ID: <b1dfca66-fbde-fa6a-ebfe-b998d69d46eb@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Glad you figured it out!

I doubt I would have. Thx!!

On 06/07/2020 14:37, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> This is enough to reproduce the problem:
>
> #include <stdio.h>
>
> typedef struct {
>     char *str;
>     int type;
> } KeywordToken;
>
> static KeywordToken *the_array[] = {
>    NULL,
>    NULL,
>    (KeywordToken[]) {
>         {"if", 510},
>         {"in", 518},
>         {"as", 520},
>         {"is", 527},
>         {"or", 532},
>         {NULL, -1},
>    },
>    NULL,
>    NULL,
>     (KeywordToken[]) {
>         {"del11", 503},
>         {"try22", 511},
>         {NULL, -1},
>     },
>     NULL
> };
>
>
> int main() {
>    for (int s=0; s<7;s++) {
>       KeywordToken *tok = the_array[s];
>       printf("--> %i\n",s);
>       if (tok == NULL) {
>          continue;
>       }
>       printf("--> %i %.*s\n", s,s, tok->str);
>    }
>    return 0;
> }
>
> [cpython (3.9)]$ xlc check_bad.c -o check_bad
> [cpython (3.9)]$ ./check_bad
> --> 0
> --> 1
> --> 2
> Segmentation fault (core dumped)
>
>
> But if you change it to:
>
> #include <stdio.h>
>
> typedef struct {
>     char *str;
>     int type;
> } KeywordToken;
>
> static KeywordToken *the_array[] = {
>      (KeywordToken[]) {{NULL, -1}},
>      (KeywordToken[]) {{NULL, -1}},
>     (KeywordToken[]) {
>         {"if", 510},
>         {"in", 518},
>         {"as", 520},
>         {"is", 527},
>         {"or", 532},
>         {NULL, -1},
>     },
>     (KeywordToken[]) {{NULL, -1}},
>     (KeywordToken[]) {{NULL, -1}},
>     (KeywordToken[]) {
>         {"del11", 503},
>         {"try22", 511},
>         {NULL, -1},
>     },
>     (KeywordToken[]) {{NULL, -1}},
> };
>
>
> int main() {
>    for (int s=0; s<7;s++) {
>       KeywordToken *tok = the_array[s];
>       if (tok == NULL) {
>          continue;
>       }
>       printf("--> %i %.*s\n", s,s, tok->str);
>    }
>    return 0;
> }
>
> [cpython (3.9)]$ xlc check.c -o check
> [cpython (3.9)]$ ./check
> --> 0
> --> 1
> --> 2 if
> --> 3
> --> 4
> --> 5 del11
> --> 6
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:35:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jul 2020 14:35:30 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594046130.59.0.536660421594.issue41208@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, unlike to marshal the pickle format is a Turing-complete language. Just loading pickle data can cause to execution of arbitrary code. marshal is more "safe" in this regard -- in worst case you can just crash when load it.

It may be interesting to make marshal deserialization more robust if it does not affect performance. But it would be a new feature, not a bug fix, and not a security fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:35:36 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 14:35:36 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594046136.77.0.57516221538.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Glad you figured it out!

Well, this is not over ;)

We should confirm that this is either a bug in XLC or a violation of C99

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:36:17 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 06 Jul 2020 14:36:17 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594046177.87.0.116807221037.issue41208@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Yes, it's like pickle, but it is not like you think.

The pickle module has a similar security disclaimer, https://docs.python.org/dev/library/pickle.html . We might agree to fix segfaults in unpickler code if the fix is simple and does not cause backwards compatibility or performance regressions. It's more likely that we decide against it because the pickle format is inherently insecure and not designed to handle untrusted data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:42:17 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 06 Jul 2020 14:42:17 +0000
Subject: [issue26205] Better specify number of nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1594046537.85.0.0503186596072.issue26205@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> There is one local namespace for each class and function.  There is one
> nonlocal namespace for each nested function.

In the first sentence, replace "class" with "class statement" and "function" with "function call". The second sentence could use "nested-function call", but maybe rewrite it as, "There is one nonlocal namespace when a nested function is called."

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26205>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:47:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jul 2020 14:47:34 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594046854.05.0.931719708561.issue41208@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In this particular case unmarshalling creates a tuple containing a reference to itself which is used as a key in a dict. Calculating a hash of such tuple leads to infinite recursion which overflows the programming stack. There is no efficient way to detect such case, and since cyclic tuples cannot be created by pure Python code we should not even try to solve this problem. You can get it only by misusing the C API or the ctypes module or loading invalid marshal data.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:59:19 2020
From: report at bugs.python.org (Brett Hannigan)
Date: Mon, 06 Jul 2020 14:59:19 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1594047559.46.0.37375335446.issue41177@roundup.psfhosted.org>


Brett Hannigan <brett.hannigan at gmail.com> added the comment:

I encountered the need for the iterators when trying to create a subclass of the QueueHandler class that would manage both the QueueHandler and the QueueListener. The implementation is very similar to that described in this Medium post:
https://medium.com/@rob.blackbourn/how-to-use-python-logging-queuehandler-with-dictconfig-1e8b1284e27a

Both the original poster and I encountered one small issue: when using a dictConfig to instantiate the new subclass, the main QueueHandler gets a ConvertingList of the handlers that the user has requested be used. The subclass would then pass these to the QueueListener, but the constructor for the QueueListener takes *handlers (that is, it will convert the ConvertingList to a tuple). Unfortunately, because ConvertingList does not expose the iterator, converting from the ConvertingList to the tuple results in a tuple of unconverted handler references (ultimately strings).

The author of the Medium article gets around this by creating a little function that simply loops over the length of the ConvertingList and does a "get" on each item on the list, to ensure that the item is converted. Since ConvertingList is not documented though, there is concern that this approach could break in the future if the interface changes etc. 

With the implementation of the iterator in this PR, the conversion of the ConvertingList to the tuple will automatically result in a tuple of converted handlers, so one doesn't need to know about the ConvertingList object - it handles things behind the scenes.

Here is the code that the Medium article currently uses to force conversion:

def _resolve_handlers(l):
    if not isinstance(l, ConvertingList):
        return l

    # Indexing the list performs the evaluation.
    return [l[i] for i in range(len(l))]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:00:52 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 06 Jul 2020 15:00:52 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
Message-ID: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>


New submission from Matthias Bussonnier <bussonniermatthias at gmail.com>:

As far as I can tell sometime in 3.8.x (likely 3.8.3) the following snippet changed result:

    import ast
    import inspect
    cell = '[x for x in l]'
    code = compile(cell, "<>", "exec", flags=getattr(ast,'PyCF_ALLOW_TOP_LEVEL_AWAIT', 0x0))

    inspect.CO_COROUTINE & code.co_flags == inspect.CO_COROUTINE


Use to be False in 3.8.2 I believe and is False after.

This is problematic when you try to detect top-level await code.

----------
components: Interpreter Core
messages: 373128
nosy: mbussonn
priority: normal
severity: normal
status: open
title: PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUTINE  falg.
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:04:05 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Mon, 06 Jul 2020 15:04:05 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594047845.73.0.0249302950997.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

It's interesting that you would not count a critical segfault in Pickle as a threat, because there are numerous libraries that are Unpickling untrusted user data (even-though some of them are using RestrictedUnpickler to protect themselves but a segfault would bypass that). For example, Ray Project with five thousands commits (https://github.com/ray-project/ray/blob/master/rllib/utils/policy_server.py#L31). 

Long story short, you advise us to not put time on checking the security of the Pickle module too, am I right?

Thanks,
Iman

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:05:31 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 06 Jul 2020 15:05:31 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594047931.93.0.0197507556939.issue41218@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

(crossref https://github.com/ipython/ipython/issues/12422)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:05:55 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 06 Jul 2020 15:05:55 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1594047955.83.0.205840982184.issue39562@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

This make non-await list comprehension coroutine-code-objects as well: 

https://bugs.python.org/issue41218

    import ast
    import inspect
    cell = '[x for x in l]'
    code = compile(cell, "<>", "exec", flags=getattr(ast,'PyCF_ALLOW_TOP_LEVEL_AWAIT', 0x0))

    inspect.CO_COROUTINE & code.co_flags == inspect.CO_COROUTINE  # this is now TRUE. 

This leads to weird things in Jupyter/IPython when we try to detect wether a block of code is, or os not async.

----------
nosy: +mbussonn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:26:28 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 06 Jul 2020 15:26:28 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594049188.02.0.661657877377.issue41208@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

That line in Ray Project is a potential arbitrary code execution vulnerability. If an attacker is able to inject a custom pickle stream, then they can easily take over the service. Please report the issue to the project. It might be a simple score of a CVE for you.

Python has several functions and modules that are not designed to deal with malicious data. They are documented as insecure. The pickle format was created 25 years ago. It's a useful serialization format but it's inherently insecure.

tl;dr we welcome any and all work to make Python more secure, but we cannot make very part of the interpreter secure. Pickle and marshal are two modules that you should ignore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:32:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 15:32:52 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1594049572.29.0.824493880433.issue39562@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:33:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 15:33:19 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1594049599.34.0.0971822825928.issue39562@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:51:41 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 06 Jul 2020 15:51:41 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1594050701.69.0.362308674061.issue41177@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

OK, seems like a reasonable use case. I haven't looked at the PR yet, as it still has a "CLA not signed" label, and I normally wait until the CLA is signed before looking more closely at PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:54:23 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 15:54:23 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594046136.77.0.57516221538.issue41215@roundup.psfhosted.org>
Message-ID: <2ef2efc1-e6d3-a658-f9f1-6cd280063bb1@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 06/07/2020 16:35, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
>> Glad you figured it out!
> Well, this is not over ;)
>
> We should confirm that this is either a bug in XLC or a violation of C99

probably a bug (that they might call a difference of implementation).

I have been testing with xlc-v11; shall also try (your simplified
example) using v13 and v16.

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:54:35 2020
From: report at bugs.python.org (Brett Hannigan)
Date: Mon, 06 Jul 2020 15:54:35 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1594050875.3.0.462016264689.issue41177@roundup.psfhosted.org>


Brett Hannigan <brett.hannigan at gmail.com> added the comment:

Thanks.

I don't know why it still says CLA not signed - I signed it a week ago, but I'll try to figure that out this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:13:30 2020
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 06 Jul 2020 16:13:30 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594052010.85.0.0019685733702.issue41215@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

I don't believe that this is an XLC bug, but I suspect that it is undefined behavior / implementation-defined behavior.

I suspect that this is tripping over AIX/XLC null behavior. AIX specifically and intentionally maps the first page of memory at address 0 to allow the compiler to speculate through NULL pointers. The compiler probably is speculating in this case and the second element is not defined.

There is some option to disable this speculation in XLC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:30:40 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 16:30:40 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594052010.85.0.0019685733702.issue41215@roundup.psfhosted.org>
Message-ID: <3f021f96-c5ab-89fa-aebc-1e5eb53e38fb@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I tried check.c and check_bad.c using xlc-v11 (on my POWER6) - and the
results were the same as in Pablo's entry.

On the gcc119 host - using the v13 compiler, check_bad does not crash.
Not gotten to testing xlc-v16 yet.

I have seen lots of options today - wheile researching, so probably,
yes. Just do not know it off the top.

Atm - testing "master" build using xlc-v11 and xlc-v13.

On 06/07/2020 18:13, David Edelsohn wrote:
> David Edelsohn <dje.gcc at gmail.com> added the comment:
>
> I don't believe that this is an XLC bug, but I suspect that it is undefined behavior / implementation-defined behavior.
>
> I suspect that this is tripping over AIX/XLC null behavior. AIX specifically and intentionally maps the first page of memory at address 0 to allow the compiler to speculate through NULL pointers. The compiler probably is speculating in this case and the second element is not defined.
>
> There is some option to disable this speculation in XLC.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:32:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jul 2020 16:32:03 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594053123.97.0.914076136266.issue29778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset dcbaa1b49cd9062fb9ba2b9d49555ac6cd8c60b5 by Steve Dower in branch 'master':
bpo-29778: Ensure python3.dll is loaded from correct locations when Python is embedded (GH-21297)
https://github.com/python/cpython/commit/dcbaa1b49cd9062fb9ba2b9d49555ac6cd8c60b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:32:15 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 16:32:15 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594053135.77.0.0819885164221.issue29778@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20497
pull_request: https://github.com/python/cpython/pull/21351

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:32:23 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 16:32:23 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594053143.82.0.309079603701.issue29778@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20498
pull_request: https://github.com/python/cpython/pull/21352

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:35:35 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Mon, 06 Jul 2020 16:35:35 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594053335.79.0.551973821612.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

Sure. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:47:19 2020
From: report at bugs.python.org (cere blanco)
Date: Mon, 06 Jul 2020 16:47:19 +0000
Subject: [issue41219] Mimetypes doesn't support audio/webm
Message-ID: <1594054039.75.0.283470806341.issue41219@roundup.psfhosted.org>


New submission from cere blanco <cereblanco at gmail.com>:

Mimetypes doesn't support audio/webm

----------
components: Library (Lib)
messages: 373140
nosy: cere blanco
priority: normal
severity: normal
status: open
title: Mimetypes doesn't support audio/webm
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41219>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:51:10 2020
From: report at bugs.python.org (Itay azolay)
Date: Mon, 06 Jul 2020 16:51:10 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
Message-ID: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>


New submission from Itay azolay <itayazolay at gmail.com>:

I'd like to add optional argument to lru_cache.
This argument is a user given function that will replace the default behaviour of creating a key from the args/kwds of the function.

for example:

def my_make_key(my_list):
  return my_list[0]

@lru_cache(128, make_key=my_make_key)
def cached_func(my_list):
  return sum(my_list)

This will creating a cached function that accepts immutable.
Also, It will allow user to add custom functions from knowledge about the expected function input, without the need to create custom classes and/or overriding __hash__

----------
components: Library (Lib)
messages: 373141
nosy: Itayazolay
priority: normal
severity: normal
status: open
title: add optional make_key argument to lru_cache
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:52:17 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 16:52:17 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594054337.17.0.92561948336.issue29778@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4981fe36c7477303de830e8dca929a02caaaffe4 by Miss Islington (bot) in branch '3.9':
bpo-29778: Ensure python3.dll is loaded from correct locations when Python is embedded (GH-21297)
https://github.com/python/cpython/commit/4981fe36c7477303de830e8dca929a02caaaffe4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:52:40 2020
From: report at bugs.python.org (Itay azolay)
Date: Mon, 06 Jul 2020 16:52:40 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594054360.24.0.802398814362.issue41220@roundup.psfhosted.org>


Change by Itay azolay <itayazolay at gmail.com>:


----------
keywords: +patch
pull_requests: +20499
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21353

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:57:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 16:57:17 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594054637.19.0.685924479795.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I don't believe that this is an XLC bug, but I suspect that it is undefined behavior / implementation-defined behavior.

I was looking at the C99 standard but could not find anything that makes this undefined. Do you know what this construct is contradicting the standard on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:03:43 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 17:03:43 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594054637.19.0.685924479795.issue41215@roundup.psfhosted.org>
Message-ID: <4a051a8f-88be-e2be-e38b-80389a2274d4@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Note: - two different systems, different HW, different OS levels.

xlc-v11, master : commit deb016224cc506503fb05e821a60158c83918ed4 (HEAD
-> master, upstream/master, upstream/HEAD)

Segmentation fault in _PyEval_EvalFrameDefault at line 941 in file
"../git/py39-3.10/Include/object.h" ($t1)
"object.h" has only 659 lines
(dbx) where
_PyEval_EvalFrameDefault(tstate = 0x300af594, f = 0x00000017, throwflag
= 15), line 941 in "object.h"
_PyEval_EvalCode(tstate = 0x1001c454, _co = 0x30092520, globals =
0x2ff20190, locals = 0x10324213, args = 0x100b2798, argcount = 44,
kwnames = 0x2ff201b0, kwargs = 0x2228228f, kwcount = 0, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x00000003, globals = 0x2ff20270, locals
= 0x2ff20220, args = 0x2004426c, argcount = 806222336, kwnames = (nil),
kwargs = 0x2ff20220, kwcount = 0, kwstep = 2, defs = (nil), defcount =
0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)),
line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10110c74, globals = 0x20095072, locals =
(nil), args = 0x300af598, argcount = 806024596, kws = 0x200950aa,
kwcount = 537481208, defs = 0x300bcf10, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
builtin___build_class__(self = 0x100b8bdc, args = (nil), nargs =
804389664, kwnames = 0x2004426c), line 222 in "bltinmodule.c"
cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x20060d88, args =
0x30046448, nargsf = 805553488, kwnames = 0x3004abb8), line 459 in
"methodobject.c"
_PyEval_EvalFrameDefault(tstate = 0x000001ff, f = 0x200012d0, throwflag
= 804390000), line 628 in "abstract.h"
_PyEval_EvalCode(tstate = 0x100d4eb4, _co = 0x3003f440, globals =
0x300b2ca8, locals = 0x300b516c, args = 0x300b5168, argcount =
805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0,
kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x300ac910, locals
= 0x2ff205b0, args = 0x2004426c, argcount = 269191840, kwnames =
0x2ff2060c, kwargs = 0xffffffff, kwcount = 0, kwstep = 2, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname =
(nil)), line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10090ab0, globals = 0x00000004, locals =
0x30062be8, args = (nil), argcount = 805624984, kws = 0x20060d88,
kwcount = 804390432, defs = 0x00000004, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x103a1254, globals = 0x103a153e, locals =
0x300d1a48), line 857 in "ceval.c"
builtin_exec_impl(module = 0x300b8ec8, source = 0x300671d8, globals =
0x2002af08, locals = 0x300af170), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x30059f6c, args = 0x30050d20, nargs = 804390720),
line 371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x101c1120, args = 0x3006906c,
nargsf = 805736544, kwnames = 0x2004426c), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0xd0129a34, tuple = 0x3008c028, kwargs =
0x2ff207f0), line 249 in "call.c"
_PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args =
0x2ff20850, kwargs = 0x0000000c), line 265 in "call.c"
do_call_core(tstate = (nil), func = (nil), callargs = 0x3003c550, kwdict
= 0x3004abb8), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0xffffffff, f = 0x300b2268, throwflag
= 805759592), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x3005e9d8, _co = 0x30062290, globals = (nil),
locals = 0x20026000, args = 0x300ac690, argcount = 805331176, kwnames =
0x2ff20a60, kwargs = 0x422822cf, kwcount = 0, kwstep = 1, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8,
qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005dbac, stack = (nil), nargsf =
805553488, kwnames = 0x30040960), line 417 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x30090e10, throwflag
= 804391856), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x300a4568, co = 0x3004a1b0, args =
0x2000af50, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x00000001, throwflag =
804392192), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3009116c, co = 0x30031176, args =
0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060d88, throwflag
= 804392528), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x00000094, co = 0x000000ab, args =
0x3003c550, nargs = 805702704, globals = 0x3004abd8), line 40 in
"pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = (nil), throwflag =
804393056), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004ab90, co = 0x3004a7c8, args =
0x2ff21020, nargs = 537150060, globals = 0x10073f98), line 40 in
"pycore_ceval.h"
object_vacall(tstate = 0x2005ee98, base = 0x20060d88, callable =
0x2ff21080, vargs = warning: Unable to access address 0x482822cf from core
(invalid char ptr (0x482822cf))), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = (nil), name = 0x20026118, ... =
0x300a9de0, 0x3003c5c8, 0x0, 0x3003ade8, 0x3003ad28, 0x3003ad48), line
901 in "call.c"
import_find_and_load(tstate = 0x3003c5e8, abs_name = 0x300a9de0), line
1765 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x300074a0,
globals = 0x300b41c0, locals = (nil), fromlist = 0x103918f0, level =
805307360), line 1885 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x300074a0, globals =
0x300b41c0, locals = (nil), fromlist = 0x103918f0, level = 805307360),
line 1885 in "import.c"
import_name(tstate = 0x20060d88, f = 0x30046448, name = 0x3003c550,
fromlist = 0x3004abb8, level = 0x3004abd8), line 5234 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x000001ff, f = 0x200012d0, throwflag
= 804393824), line 3120 in "ceval.c"
_PyEval_EvalCode(tstate = 0x100d4eb4, _co = 0x3003f440, globals =
0x3008e908, locals = 0x30046f2c, args = 0x30046f28, argcount =
805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0,
kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x30090d48, locals
= 0x2ff214a0, args = 0x2004426c, argcount = 269191840, kwnames =
0x2002e470, kwargs = 0xffffffff, kwcount = 0, kwstep = 2, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname =
(nil)), line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10090ab0, globals = 0x00000004, locals =
0x30062be8, args = (nil), argcount = 805624984, kws = 0x20060d88,
kwcount = 804394256, defs = 0x00000004, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x103a1254, globals = 0x103a153e, locals =
0x300b41c0), line 857 in "ceval.c"
builtin_exec_impl(module = 0x300b2288, source = 0x300671d8, globals =
0x2002af08, locals = 0x300af170), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x30059f6c, args = 0x30050d20, nargs = 804394544),
line 371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x101c1120, args = 0x3006906c,
nargsf = 805736544, kwnames = 0x2004426c), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0xd0129a34, tuple = 0x3008c028, kwargs =
0x2ff216e0), line 249 in "call.c"
_PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args =
0x2ff21740, kwargs = 0x0000000c), line 265 in "call.c"
do_call_core(tstate = (nil), func = (nil), callargs = 0x3003c550, kwdict
= 0x3004abb8), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0xffffffff, f = 0x3008e188, throwflag
= 805758120), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x3005e9d8, _co = 0x30062290, globals = (nil),
locals = 0x20026000, args = 0x30090d20, argcount = 805331176, kwnames =
0x2ff21950, kwargs = 0x422822cf, kwcount = 0, kwstep = 1, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8,
qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005d8bc, stack = (nil), nargsf =
805553488, kwnames = 0x30040960), line 417 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x30088a00, throwflag
= 804395680), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x30087520, co = 0x3004a1b0, args =
0x2000af50, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x00000001, throwflag =
804396016), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004289c, co = 0x30031176, args =
0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060d88, throwflag
= 804396352), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x00000094, co = 0x000000ab, args =
0x3003c550, nargs = 0, globals = 0x3004abd8), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x102e59dc, f = (nil), throwflag =
804396880), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004ab90, co = 0x3004a7c8, args =
0x2ff21f10, nargs = 537150060, globals = 0x10073f98), line 40 in
"pycore_ceval.h"
object_vacall(tstate = 0x2005ee98, base = 0x20060d88, callable =
0x2ff21f70, vargs = warning: Unable to access address 0x482822cf from core
(invalid char ptr (0x482822cf))), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = (nil), name = 0x20026118, ... =
0x3008d520, 0x3003c5c8, 0x0, 0x3003ade8, 0x3003ad28, 0x3003ad48), line
901 in "call.c"
import_find_and_load(tstate = 0x2003e4a0, abs_name = (nil)), line 1765
in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30085e10,
globals = (nil), locals = 0x103a18c0, fromlist = 0x20037780, level =
804397264), line 1885 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30085e10, globals = (nil),
locals = 0x103a18c0, fromlist = 0x20037780, level = 804397264), line
1885 in "import.c"
builtin___import__(self = 0x100bead4, args = 0x00000010, kwds =
0x2ff22140), line 280 in "bltinmodule.c"
cfunction_call(func = 0x20060d88, args = 0x3003c528, kwargs = (nil)),
line 537 in "methodobject.c"
_PyObject_MakeTpCall(tstate = (nil), callable = 0x2ff2227c, args =
0x2ff22220, nargs = 673718991, keywords = 0x100bc874), line 197 in "call.c"
_PyObject_CallFunctionVa(tstate = 0xa23d56d8, callable = (nil), format =
warning: Unable to access address 0xdeadbeef from core
(invalid char ptr (0xdeadbeef)), va = (nil), is_size_t = 0), line 65592
in "abstract.h"
PyObject_CallFunction(callable = 0x3003c5c8, format = "OOOOi", ... =
0x3008d520, 0x30085e60, 0x30085e60, 0x3006afe8, 0x0, 0x0), line 583 in
"call.c"
PyImport_Import(module_name = 0x2ff22460), line 2086 in "import.c"
PyImport_ImportModule(name = "\200A"), line 1482 in "import.c"
PyImport_ImportModuleNoBlock(name = "`"), line 1500 in "import.c"
_PyCodecRegistry_Init(), line 1547 in "codecs.c"
_PyCodec_Forget(encoding = warning: Unable to access address 0xa23d56d8
from core
(invalid char ptr (0xa23d56d8))), line 128 in "codecs.c"
init_stdio_encoding(tstate = 0x2ff22534), line 15996 in "unicodeobject.c"
init_fs_encoding(tstate = 0x20008148), line 16110 in "unicodeobject.c"
_PyUnicode_InitEncodings(tstate = 0x200010f0), line 16126 in
"unicodeobject.c"
init_interp_main(tstate = 0x00000001), line 1016 in "pylifecycle.c"
pyinit_main(tstate = 0x200010f0), line 1107 in "pylifecycle.c"
Py_InitializeFromConfig(config = (nil)), line 1151 in "pylifecycle.c"
pymain_init(args = 0xf066a338), line 66 in "main.c"
pymain_main(args = 0x00000001), line 694 in "main.c"
Py_BytesMain(argc = -559038737, argv = 0xdeadbeef), line 727 in "main.c"
python.main(argc = 0, argv = (nil)), line 15 in "python.c"
(dbx)

+++++++++++++ xlc-v13 +++++++++++++

Looks about the same: master : commit
deb016224cc506503fb05e821a60158c83918ed4

aixtools at gcc119:[/home/aixtools/python/cpython]dbx ./python core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...

Segmentation fault in _PyEval_EvalFrameDefault at line 1125 in file
"Include/object.h" ($t1)
"object.h" has only 659 lines
(dbx) where
_PyEval_EvalFrameDefault(tstate = 0x100f6370, f = (nil), throwflag =
537443004), line 1125 in "object.h"
_PyEval_EvalCode(tstate = 0x1001eb04, _co = 0x30039ae8, globals =
0x2ff1ffc0, locals = 0x20044858, args = 0x1001ede4, argcount =
806047904, kwnames = 0x2ff1ffa0, kwargs = 0x103b0233, kwcount = 0,
kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x1013e6b8, globals = 0x300ae5a0, locals
= 0x300bcec8, args = 0x20044858, argcount = 536872576, kwnames = (nil),
kwargs = 0x2ff20030, kwcount = -2077998513, kwstep = 2, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname =
(nil)), line 4397 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x101332d0, globals = 0x2000d9a8, locals =
0x300ae598, args = 0x2009d4ba, argcount = 537515016, kws = 0x30083e68,
kwcount = 805435232, defs = 0x300bcec8, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
builtin___build_class__(self = 0x100bab9c, args = 0x3003c550, nargs =
804389168, kwnames = 0x20044858), line 222 in "bltinmodule.c"
cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x100fbdb4, args =
0x300d0538, nargsf = 804389264, kwnames = 0x20044858), line 459 in
"methodobject.c"
_PyEval_EvalFrameDefault(tstate = 0x30016988, f = 0x200673d8, throwflag
= 805399252), line 812 in "abstract.h"
_PyEval_EvalCode(tstate = 0x00000004, _co = 0x200654a4, globals =
0x00000043, locals = 0x00000001, args = (nil), argcount = 537293784,
kwnames = 0x300b716c, kwargs = 0x3004447c, kwcount = 0, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x200654ac, globals = 0x300dce38, locals
= 0x300abd20, args = 0x300b1ca8, argcount = 806169160, kwnames =
0x300abd20, kwargs = 0x2ff203d0, kwcount = 804390176, kwstep = 2, defs =
(nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 4397 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x100abe24, globals = 0x200654a4, locals =
0x300ae190, args = 0x10407c00, argcount = 806019444, kws = 0x200673d8,
kwcount = 804389952, defs = (nil), defcount = 0, kwdefs = (nil), closure
= (nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x101fb228, globals = 0x10417960, locals =
0x300d2a48), line 857 in "ceval.c"
IPRA.$builtin_exec_impl(module = 0x1008cd6c, source = 0x30046448,
globals = 0x2ff204d0, locals = 0x20044858), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x30059f7c, args = (nil), nargs = 805536424), line
371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x200003c8, args = 0x300b8e60,
nargsf = 804390272, kwnames = 0x200673d8), line 424 in "methodobject.c"
PyVectorcall_Call(callable = 0x100f94b4, tuple = 0x20006888, kwargs =
0x2ff20600), line 249 in "call.c"
_PyObject_Call(tstate = 0x300b7028, callable = 0x200673d8, args =
0x2ff20640, kwargs = 0x10407c00), line 265 in "call.c"
do_call_core(tstate = (nil), func = (nil), callargs = 0x2ff206a0, kwdict
= 0x3004abb8), line 5130 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x30027cb0, f = 0x30063aa8, throwflag
= 805628416), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x300462e8, _co = 0x200673d8, globals =
0x2ff20840, locals = 0x48242242, args = 0x1008ddd0, argcount =
805896992, kwnames = 0x2ff20840, kwargs = 0x20044858, kwcount = 0,
kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = 0x300197c8, qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x100b2d30, stack = 0x200654a4, nargsf =
804391088, kwnames = 0x3000c254), line 398 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x3004a098, f = 0x30090320, throwflag
= 804391328), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x1008bc64, co =
0x200673d8, args = 0x2ff20a00, nargs = 537151576, globals = 0x1008ddd0),
line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x1008bc64, co = 0x200673d8, args
= 0x2ff20a00, nargs = 537151576, globals = 0x1008ddd0), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x10141878, stack = 0x3004a1b0, nargsf =
804391520, kwnames = 0x10407c00), line 366 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200324d0, f = 0x30056c88, throwflag
= 805698224), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x100b6a14, co =
0x200654a4, args = 0x2ff20bc0, nargs = 537151576, globals = 0x3005f958),
line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x100b6a14, co = 0x200654a4, args
= 0x2ff20bc0, nargs = 537151576, globals = 0x3005f958), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x200654ac, stack = 0x200654a4, nargsf =
805904756, kwnames = 0x3003116e), line 366 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x100b4834, f = 0x30035b40, throwflag
= 804392240), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x100b6a14, co =
0x200673d8, args = 0x2ff20d80, nargs = 537151576, globals = 0x1008ddd0),
line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x100b6a14, co = 0x200673d8, args
= 0x2ff20d80, nargs = 537151576, globals = 0x1008ddd0), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0xd0584b0c, stack = 0x200673d8, nargsf =
537285796, kwnames = 0xf02ff01c), line 366 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10085584, f = 0x300a9da0, throwflag
= 805547336), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = (nil), co =
(nil), args = 0x2ff20f40, nargs = 805508802, globals = 0x10058d4c), line
40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = (nil), co = (nil), args =
0x2ff20f40, nargs = 805508802, globals = 0x10058d4c), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3004a7c8, stack = 0x3004ab90, nargsf =
804392896, kwnames = (nil)), line 366 in "call.c"
IPRA.$object_vacall(tstate = 0x100a8ee8, base = 0x30035ac8, callable =
0x2ff21030, vargs = "j^Aj^B|^Ak^Er2|"), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = 0x300a9da0, name = 0x2000d9f0, ... =
0x300a9da0, 0x3003c5c8, 0x0, 0x3003ae08, 0x3003ad48, 0x3003ad68), line
901 in "call.c"
IPRA.$import_find_and_load(tstate = 0x300b3028, abs_name = 0x200673d8),
line 1765 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x00000002, globals =
0x200654a4, locals = 0x2ff21160, fromlist = 0x00000001, level =
269199964), line 1866 in "import.c"
IPRA.$import_name(tstate = 0x100fbdb4, f = 0x300b2ad8, name =
0x2ff211c0, fromlist = 0x20044858, level = 0x100c57c8), line 5234 in
"ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x30016988, f = 0x200673d8, throwflag
= 805399252), line 3120 in "ceval.c"
_PyEval_EvalCode(tstate = 0x00000004, _co = 0x200654a4, globals =
0x00000043, locals = 0x00000001, args = (nil), argcount = 537293784,
kwnames = 0x30046f2c, kwargs = 0x3004447c, kwcount = 0, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x200654ac, globals = 0x30090208, locals
= 0x30090190, args = 0x3008e8c8, argcount = 806027712, kwnames =
0x30090190, kwargs = 0x2ff21400, kwcount = 804394320, kwstep = 2, defs =
(nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 4397 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x100abe24, globals = 0x200654a4, locals =
(nil), args = 0x10407c00, argcount = 536914064, kws = 0x200673d8,
kwcount = 804394096, defs = (nil), defcount = 0, kwdefs = (nil), closure
= (nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x101fb228, globals = 0x10417960, locals =
0x300b01c0), line 857 in "ceval.c"
IPRA.$builtin_exec_impl(module = 0x1008cd6c, source = 0x30046448,
globals = 0x2ff21500, locals = 0x20044858), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x2006fcd8, args = 0x30068028, nargs = 805740328),
line 371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x200003c8, args = 0x300b1220,
nargsf = 804394416, kwnames = 0x200673d8), line 424 in "methodobject.c"
PyVectorcall_Call(callable = 0x100f94b4, tuple = 0x20006888, kwargs =
0x2ff21630), line 249 in "call.c"
_PyObject_Call(tstate = 0x30046de8, callable = 0x200673d8, args =
0x2ff21670, kwargs = 0x10407c00), line 265 in "call.c"
do_call_core(tstate = (nil), func = (nil), callargs = 0x2ff216d0, kwdict
= 0x3004abb8), line 5130 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x30027cb0, f = 0x30063aa8, throwflag
= 805628416), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x30046c88, _co = 0x200673d8, globals =
0x2ff21870, locals = 0x48242242, args = 0x1008ddd0, argcount =
805896512, kwnames = 0x2ff21870, kwargs = 0x20044858, kwcount = 0,
kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = 0x300197c8, qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x100b2d30, stack = 0x200654a4, nargsf =
805685444, kwnames = 0x3000c254), line 398 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x3004a098, f = 0x30090140, throwflag
= 804395472), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x1008bc64, co =
0x200673d8, args = 0x2ff21a30, nargs = 537151576, globals = 0x1008ddd0),
line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x1008bc64, co = 0x200673d8, args
= 0x2ff21a30, nargs = 537151576, globals = 0x1008ddd0), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x10141878, stack = 0x3004a1b0, nargsf =
804395664, kwnames = 0x10407c00), line 366 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200324d0, f = 0x30056c88, throwflag
= 805696656), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x100b6a14, co =
0x200654a4, args = 0x2ff21bf0, nargs = 537151576, globals = 0x3005f338),
line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x100b6a14, co = 0x200654a4, args
= 0x2ff21bf0, nargs = 537151576, globals = 0x3005f338), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x200654ac, stack = 0x200654a4, nargsf =
805578916, kwnames = 0x3003116e), line 366 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x100b4834, f = 0x30035b40, throwflag
= 804396384), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x100b6a14, co =
0x200673d8, args = 0x2ff21db0, nargs = 537151576, globals = 0x1008ddd0),
line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x100b6a14, co = 0x200673d8, args
= 0x2ff21db0, nargs = 537151576, globals = 0x1008ddd0), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x30040788, stack = 0x30067f40, nargsf =
804396592, kwnames = 0x2ff21f68), line 366 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10085584, f = 0x3008d930, throwflag
= 805547336), line 812 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x10396408, co =
0x10351cc8, args = 0x2ff21f70, nargs = -559038737, globals =
0x10058d4c), line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x10396408, co = 0x10351cc8, args
= 0x2ff21f70, nargs = -559038737, globals = 0x10058d4c), line 40 in
"pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3004a7c8, stack = 0x3004ab90, nargsf =
804397040, kwnames = (nil)), line 366 in "call.c"
IPRA.$object_vacall(tstate = 0x100a8ee8, base = 0x30035ac8, callable =
0x2ff22060, vargs = ""), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = 0x3008d930, name = 0x2000d9f0, ... =
0x3008d930, 0x3003c5c8, 0x0, 0x3003ae08, 0x3003ad48, 0x3003ad68), line
901 in "call.c"
IPRA.$import_find_and_load(tstate = 0x300872a8, abs_name = 0x3003c5c8),
line 1765 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x100b3b8c, globals =
0x30087258, locals = 0x2ff22180, fromlist = 0x20037f68, level =
804397424), line 1866 in "import.c"
builtin___import__(self = 0x100c0e34, args = 0xdeadbeef, kwds =
0x3003c528), line 280 in "bltinmodule.c"
cfunction_call(func = 0x103a3ee8, args = 0x200673d8, kwargs = (nil)),
line 556 in "methodobject.c"
_PyObject_MakeTpCall(tstate = 0x1009c318, callable = 0x3003c528, args =
(nil), nargs = 537151576, keywords = 0x1008cd6c), line 191 in "call.c"
IPRA.$_PyObject_CallFunctionVa(tstate = 0x00000006, callable =
0x2ff22b98, format =
"/\362,Z/\362,e/\362,p/\362,\177/\362,\223/\362,\244/\362,\306/\362-R/\362-c/\362-v/\362-\207/\362-\225/\362-\263/\362-\314/\362-\347/\362-\365/\362.^F/\362.^P/\362.^^/\362.3/\362.G/\362.j/\362.\236/\362.\251/\362.\305/\362.\347/\362.\357/\362.\376",
va = "0^F\177\2300^F\177\2000^H\33100", is_size_t = -559038737), line
65592 in "abstract.h"
PyObject_CallFunction(callable = 0x103a5bf8, format = "OOOOi", ... =
0x3008d930, 0x300872a8, 0x300872a8, 0x3006bf88, 0x0, 0x0), line 564 in
"call.c"
PyImport_Import(module_name = 0x10132904), line 2086 in "import.c"
PyImport_ImportModule(name = ""), line 1482 in "import.c"
_PyCodecRegistry_Init(), line 1547 in "codecs.c"
_PyCodec_Forget(encoding = warning: Unable to access address 0x460d2abe
from core
(invalid char ptr (0x460d2abe))), line 128 in "codecs.c"
init_stdio_encoding(tstate = 0x00000008), line 15996 in "unicodeobject.c"
init_fs_encoding(tstate = 0x2ff22600), line 16110 in "unicodeobject.c"
_PyUnicode_InitEncodings(tstate = (nil)), line 16126 in "unicodeobject.c"
IPRA.$init_interp_main(tstate = 0x00000001), line 1016 in "pylifecycle.c"
pyinit_main(tstate = (nil)), line 1107 in "pylifecycle.c"
Py_InitializeFromConfig(config = 0xf0301cd4), line 1151 in "pylifecycle.c"
IPRA.$pymain_init(args = 0x2ff22aa0), line 66 in "main.c"
pymain_main(args = 0x00000006), line 694 in "main.c"
Py_BytesMain(argc = -559038737, argv = 0xdeadbeef), line 727 in "main.c"
python.main(argc = 0, argv = (nil)), line 15 in "python.c"
(dbx)

On 06/07/2020 18:57, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
>> I don't believe that this is an XLC bug, but I suspect that it is undefined behavior / implementation-defined behavior.
> I was looking at the C99 standard but could not find anything that makes this undefined. Do you know what this construct is contradicting the standard on?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:05:17 2020
From: report at bugs.python.org (mike bayer)
Date: Mon, 06 Jul 2020 17:05:17 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594055117.93.0.584912971932.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

hey there,

I seem to have two cents to offer so here it is.    An obscure issue in the Python bug tracker is probably not the right place for this so consider this as an early draft of something that maybe I'll talk about more elsewhere.

> This basically divides code into two islands - async and non-async

yes, this is the problem, and at the bottom of this apparently somewhat ranty comment is a solution, and the good news is that it does not require Python or asyncio be modified.  My concern is kind of around how it is that everyone has been OK with the current state of affairs for so long, why it is that "asyncio is fundamentally incompatible with library X" is considered to be acceptable, and also how easy it was to find a workaround, this is not something I would have expected to come up with.  Kind of like you don't expect to invent Velcro or windshield wipers.

asyncio's approach is what those of us in the library/framework community call "explicit async", you have to mark functions that will be doing IO and the points at which IO occurs must also be marked.    Long ago it was via callback functions, then asyncio turned it into decorators and yields, and finally pep492 turned it into async/await, and it is very nicely done.  It is of course a feature of asyncio that writing out async/await means your code can in theory be clearer as to where IO occurs and all that, and while I don't totally buy that myself, I'm of course in favor of that style of coding being available, it definitely has its own kind of self-satisfaction built in when you do it.  That's all great.

But as those of us in the library/framework community also know, asyncio's approach essentially means, libraries like Flask, Django, my own SQLAlchemy, etc. are all automatically "non-workable" with the asyncio approach; while these libraries can certainly have asyncio endpoints added to them, the task as designed is not that simple, since to go from an asyncio endpoint all the way through library code that doesn't care about async and then down into a networking library that again has asyncio endpoints, the publishing of "async" and the "await" or yield approach must be wired all the way through every function and method.  This is all despite that when you're not at the endpoints, the points at which IO occurs is fully predictable such that libraries like gevent don't need you to write it.   So we are told that libraries have to have full end-to-end rewrites of all their code to work this way, or otherwise maintain two codebases, or something like that.

The side effect of this is that a whole bunch of library and framework authors now get to create all new libraries and frameworks, which do exactly the same thing as all the existing libraries and frameworks, except they sprinkle the "async/await" keywords throughout middle tiers as required.  Vague claims of "framework X is faster because it's async" appear, impossible to confirm as it is unknown how much of their performance gains come from the "async" aspect and how much of it is that they happened to rewrite a new framework from scratch in a completely different way (hint: it's the latter).

Or in other cases, as if to make it obvious how much the "async/await" keywords come down to being more or less boilerplate for the "middle" parts of libraries, the urllib3 project wrote the "unasync" project [1] so that they can simply maintain two separate codebases, one that has "async/await" and  the other which just search-and-replaced them out.

SQLAlchemy has not been "replaced" by this trend as asyncio database libraries have not really taken off in Python, and there are very few actual async drivers.   Some folks have written SQLAlchemy-async libraries that use SQLAlchemy's expression system while they have done the tedious, redundant and impossible-to-maintain work of replicating enough of SQLAlchemy's execution internals such that a modest "sqlalchemy-like" experience with asyncio can be reproduced. But these libraries are closed out from all of the fixes and improvements that occur to SQLAlchemy itself, as well as that these systems likely target a smaller subset of SQLAlchemy's behaviors and features in any case.    They certainly can't get the ORM working as the ORM runs lots of SQL executions internally, all of which would have to propagate their "asyncness" outwards throughout hundreds of functions.

The asyncpg project, one of the few asyncio database drivers that exists, notes in its FAQ "asyncpg uses asynchronous execution model and API, which is fundamentally incompatible with SQLAlchemy" [2], yet we know this is not true  because SQLAlchemy works just fine with gevent and eventlet, with no architectural changes at all.  Using libraries like SQLAlchemy or Django with a non-blocking IO, event-based model is commonplace.   It's the "explicit" part of it that is hard, which is because of how asyncio is designed, without any mediation for code that doesn't publish "async / await" keywords in the middle.

So I finally just sat down to figure out how to use the underlying greenlet library (which we all know as the portable version of "Stackless Python") to bridge the gap between asyncio and blocking-style code, it's about 30 lines and I have SQLAlchemy working with an async front-end to asyncpg DBAPI as can be seen at [3] based on the proof of concept at [4].  I'm actually running the full py.test suite all inside the asyncio event loop and running asyncpg through SQLAlchemy's whole battery of thousands of tests, all of them written in purely blocking style, and there's not any need to add "async / await / yield / etc" anywhere except the very endpoints, that is, where the top function is called, and then down where we call into asyncpg directly, using a function called await_() that works just like the "await" keyword.  Just no "async" function declaration.

A day later, someone took the same idea and got Flask to work in an asyncio event loop at [5].  The general idea of using greenlet in this way is also present at [6], so I won't be patenting this idea today as oremanj can claim prior art.

Using greenlet, there is no need to break out of the asyncio event loop at all, nor does it change the control flow of parallel coroutines within the loop. It uses greenlet's "switch", quite minimally, to bridge the gap between code that does not push out an "async/await" yield and code that does.   There are no threadpools, no alternate event loops, no monkeypatching, just a few greenlet.switch() calls in the right spots.   A slight performance decrease of about 15%, but in theory one would only be using asyncio if their application is expected to be IO bound in any case (which folks that know me know is another assertion I frequently doubt).

So to sum up, last week, libraries like Flask and SQLAlchemy were "fundamentally incompatible" with asyncio, and this week they are not.    What's confusing me is that I'm not that smart and this is something all of the affected libraries should have been doing years ago, and really, while I know this is not going to happen, this should be *part of asyncio itself* or at least a very standard approach so that nobody has to assume asyncio means "rewrite all your library code".

To add an extra bonus, you can use this greenlet approach to have blocking-style functions right in the middle of your otherwise asyncio application.  Which means this also is a potential solution to the "lazy-loading" problem.  You have an asyncio app that does lots of asyncio to talk to microservices, but some functions are doing database work and they really would like to just work in a transaction, load some objects and access their attributes without worrying that a SQL statement can't be emitted.  This approach makes that possible as well.  ORM lazy loading with the asyncpg driver: [7]  .     Indeed, if you have a PostgreSQL SQLAlchemy application already written in blocking style, you can use this new extension and drop the entire application into the event loop and use the asyncpg driver, not too unlike using gevent except nothing is monkeypatched.

The recipe is simple and so far appears to be very effective.   Using greenlet to manipulate the stack is of course "spooky" and I would assume Python devs may propose that this would lead to hard-to-debug conditions.   I've used gevent and eventlet for many years and while they do produce some new issues, most of them relate to the fact that they use monkeypatching of existing modules and particularly around low level network drivers like pymysql.  The actual stack moving around within business logic doesn't seem to produce any difficult new issues.   Using plain asyncio has a lot of novel and confusing failure modes too.    Using the little bit of "spookyness" of greenlet IMO is a lot less work than rewriting SQLAlchemy, Django ORM, Flask, urllib3, etc. from scratch and maintaining two codebases though.


[1] https://pypi.org/project/unasync/

[2] https://magicstack.github.io/asyncpg/current/faq.html#can-i-use-asyncpg-with-sqlalchemy-orm

[3] https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/2071

[4] https://gist.github.com/zzzeek/4e89ce6226826e7a8df13e1b573ad354

[5] https://twitter.com/miguelgrinberg/status/1279894131976921088

[6] https://github.com/oremanj/greenback

[7] https://gerrit.sqlalchemy.org/plugins/gitiles/sqlalchemy/sqlalchemy/+/refs/changes/71/2071/10/examples/asyncio/greenlet_orm.py

----------
nosy: +zzzeek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:10:40 2020
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 06 Jul 2020 17:10:40 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594055440.07.0.408267933376.issue41215@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Maybe XLC was being overly aggressive with speculation and it now is fixed. I can't tell if Michael's earlier comment meant that it no longer crashes with XLC v16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:12:23 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 06 Jul 2020 17:12:23 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594055543.72.0.637804421001.issue29778@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset aa7f7756149a10c64d01f583b71e91814db886ab by Miss Islington (bot) in branch '3.8':
bpo-29778: Ensure python3.dll is loaded from correct locations when Python is embedded (GH-21297) (GH-21352)
https://github.com/python/cpython/commit/aa7f7756149a10c64d01f583b71e91814db886ab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:13:55 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 17:13:55 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594055635.09.0.91384004728.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Well, in any case, I will submit a patch today to the parser generator to substitute the NULL for single-element arrays which seems to work.

Michael, could you confirm that this patch works for you:

diff --git a/Parser/pegen/parse.c b/Parser/pegen/parse.c
index 9d3ac575df..e5511bf815 100644
--- a/Parser/pegen/parse.c
+++ b/Parser/pegen/parse.c
@@ -1,6 +1,6 @@
-// @generated by pegen.py from ./Grammar/python.gram
-#include "pegen.h"

+#include "pegen.h"
+// @generated by pegen.py from ./Grammar/python.gram
 #if defined(Py_DEBUG) && defined(Py_BUILD_CORE)
 extern int Py_DebugFlag;
 #define D(x) if (Py_DebugFlag) x;
@@ -9,8 +9,8 @@ extern int Py_DebugFlag;
 #endif
 static const int n_keyword_lists = 15;
 static KeywordToken *reserved_keywords[] = {
-    NULL,
-    NULL,
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
     (KeywordToken[]) {
         {"if", 510},
         {"in", 518},
@@ -65,11 +65,11 @@ static KeywordToken *reserved_keywords[] = {
         {"nonlocal", 509},
         {NULL, -1},
     },
-    NULL,
-    NULL,
-    NULL,
-    NULL,
-    NULL,
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
+    (KeywordToken[]) {{NULL, -1}},
     (KeywordToken[]) {
         {"__peg_parser__", 531},
         {NULL, -1},
@@ -24735,7 +24735,6 @@ _PyPegen_parse(Parser *p)
     // Initialize keywords
     p->keywords = reserved_keywords;
     p->n_keyword_lists = n_keyword_lists;
-
     // Run parser
     void *result = NULL;
     if (p->start_rule == Py_file_input) {

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:16:38 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jul 2020 17:16:38 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594055798.3.0.78995688717.issue41215@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Pablo, I can do that as well, if you don't have the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:25:03 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Jul 2020 17:25:03 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594056303.18.0.639782461724.issue29778@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 110dd153662a13b8ae1bb06348e5b1f118ab26d7 by Steve Dower in branch '3.7':
[3.7] bpo-29778: Ensure python3.dll is loaded from correct locations when Python is embedded (GH-21297) (#21298)
https://github.com/python/cpython/commit/110dd153662a13b8ae1bb06348e5b1f118ab26d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:33:53 2020
From: report at bugs.python.org (Manuel Jacob)
Date: Mon, 06 Jul 2020 17:33:53 +0000
Subject: [issue41221] Output of print() might get truncated in unbuffered mode
Message-ID: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>


New submission from Manuel Jacob <me at manueljacob.de>:

Without unbuffered mode, it works as expected:

% python -c "import sys; sys.stdout.write('x'*4294967296)" | wc -c        
4294967296

% python -c "import sys; print('x'*4294967296)" | wc -c 
4294967297

With unbuffered mode, writes get truncated to 2147479552 bytes on my Linux machine:

% python -u -c "import sys; sys.stdout.write('x'*4294967296)" | wc -c           
2147479552

% python -u -c "import sys; print('x'*4294967296)" | wc -c 
2147479553

I didn?t try, but it?s probably an even bigger problem on Windows, where writes might be limited to 32767 bytes: https://github.com/python/cpython/blob/v3.9.0b4/Python/fileutils.c#L1585

Without unbuffered mode, `sys.stdout.buffer` is a `io.BufferedWriter` object.

% python -c 'import sys; print(sys.stdout.buffer)'
<_io.BufferedWriter name='<stdout>'>

With unbuffered mode, `sys.stdout.buffer` is a `io.FileIO` object.

% python -u -c 'import sys; print(sys.stdout.buffer)' 
<_io.FileIO name='<stdout>' mode='wb' closefd=False>

`io.BufferedWriter` implements the `io.BufferedIOBase` interface. `io.BufferedIOBase.write()` is documented to write all passed bytes. `io.FileIO` implements the `io.RawIOBase` interface. `io.RawIOBase.write()` is documented to be able to write less bytes than passed.

`io.TextIOWrapper.write()` is not documented to write all characters it has been passed, but e.g. `print()` relies on that.

To fix the problem, it has to be ensured that either
* `sys.stdout.buffer` is an object that guarantees that all bytes passed to its `write()` method are written (e.g. deriving from `io.BufferedIOBase`), or
* `io.TextIOWrapper` calls the `write()` method of its underlying binary stream until all bytes have been written, or
* users of `io.TextIOWrapper` call `write()` until all characters have been written.

In the first two possibilities it probably makes sense to tighten the contract of `io.TextIOBase.write` to guarantee that all passed characters are written.

----------
components: IO
messages: 373151
nosy: mjacob
priority: normal
severity: normal
status: open
title: Output of print() might get truncated in unbuffered mode
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:42:49 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Mon, 06 Jul 2020 17:42:49 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593549875.63.0.81357373837.issue41176@roundup.psfhosted.org>
Message-ID: <1594057369.24.0.862388488853.issue41176@roundup.psfhosted.org>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

I'm planning to write the long-awaited Tkinter Internals section of the docs. (https://github.com/python/cpython/blame/master/Doc/library/tk.rst#L48) I've spent too much time at this point to let it all go down the memory hole. Unfortunately, I don't know how ALL of the internals work. Is there someone else we could add to nosy that might be interested in writing some subsections?

Also, should this extended docs contribution be a new issue or rolled in with this one? Much abbreviated documentation of the new methods in this PR could be added to tkinter.rst. The new docs issue would be dependent on this issue since I won't be able to complete the docs until we have finished discussing what the future behavior of threads waiting for `dispatching` will be (error & poll vs Tcl_ConditionWait).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41176>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:47:50 2020
From: report at bugs.python.org (Bar Harel)
Date: Mon, 06 Jul 2020 17:47:50 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594057670.29.0.553394559792.issue41220@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

May I suggest calling it key? Will comply with other Python functions.

----------
nosy: +bar.harel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:50:31 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jul 2020 17:50:31 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594057831.74.0.0160186579669.issue41220@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:35:29 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jul 2020 18:35:29 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594060529.99.0.31852046589.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20500
pull_request: https://github.com/python/cpython/pull/21354

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:35:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 18:35:31 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594060531.26.0.543905899835.issue41215@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +20501
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21355

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:35:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 18:35:22 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594060522.77.0.847802952618.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Pablo, I can do that as well, if you don't have the time.

Thanks! I had the PR ready, just needed some time to push it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:47:05 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 18:47:05 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594061225.13.0.512412150402.issue41215@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +20502
pull_request: https://github.com/python/cpython/pull/21356

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:55:47 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Jul 2020 18:55:47 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594061747.43.0.0167095556866.issue29778@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 46cbf6148a46883110883488d3e9febbe46ba861 by Steve Dower in branch '3.6':
[3.6] bpo-29778: Ensure python3.dll is loaded from correct locations when Python is embedded (GH-21298) (#21354)
https://github.com/python/cpython/commit/46cbf6148a46883110883488d3e9febbe46ba861


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:57:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jul 2020 18:57:21 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594061841.11.0.884308573654.issue29778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Fixes are in. Also adding the CVE number to the bug title.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath -> [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:21:26 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 06 Jul 2020 19:21:26 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594063286.41.0.918907785189.issue41218@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

https://bugs.python.org/issue39562 seem to have triggered that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:23:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jul 2020 19:23:17 +0000
Subject: [issue41162] Clear audit hooks after destructors
In-Reply-To: <1593448091.24.0.691665000355.issue41162@roundup.psfhosted.org>
Message-ID: <1594063397.32.0.61621578533.issue41162@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Merged the initial fix, but we now need to find any exploitable paths that remain.

Considering how late in finalization they now run, they're very unlikely to succeed at doing anything interesting. However, they'd also qualify as bugs (potentially crashes), so we'll want to find ways to make them run earlier anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41162>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:25:58 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 06 Jul 2020 19:25:58 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594063558.72.0.687406201282.issue41218@roundup.psfhosted.org>


Change by Matthias Bussonnier <bussonniermatthias at gmail.com>:


----------
keywords: +patch
pull_requests: +20503
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21357

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:27:57 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 06 Jul 2020 19:27:57 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1594063677.38.0.961082344479.issue39562@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

Pablo, I see you reopened and marked as blocker, 

As the changes here has been released maybe you want to reclose and marked https://bugs.python.org/issue41218 as blocker it should also be fixed by
https://github.com/python/cpython/pull/21357

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:30:03 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 19:30:03 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594063803.12.0.037470716468.issue41215@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 54f115dd533653c43b3c5541bf5936b22e484474 by Pablo Galindo in branch '3.9':
[3.9] bpo-41215: Don't use NULL by default in the PEG parser keyword list (GH-21355) (GH-21356)
https://github.com/python/cpython/commit/54f115dd533653c43b3c5541bf5936b22e484474


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:31:19 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 19:31:19 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594063879.71.0.24160134831.issue41215@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1ac0cbca369f16f9191833dd54536482fb141a98 by Pablo Galindo in branch 'master':
bpo-41215: Don't use NULL by default in the PEG parser keyword list (GH-21355)
https://github.com/python/cpython/commit/1ac0cbca369f16f9191833dd54536482fb141a98


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:42:29 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 19:42:29 +0000
Subject: [issue37724] [[Errno 17] File exists: ] # Try create directories that
 are not part of the archive with
In-Reply-To: <1564525622.36.0.964910267569.issue37724@roundup.psfhosted.org>
Message-ID: <1594064549.56.0.709755870994.issue37724@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

This is marked 2.7 is it still relevant?

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37724>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:45:12 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 19:45:12 +0000
Subject: [issue41014] warning: 'sqlite3_trace' is deprecated
In-Reply-To: <1592436367.99.0.294210468626.issue41014@roundup.psfhosted.org>
Message-ID: <1594064712.56.0.490403847323.issue41014@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I think the same reasoning in the discussion from this thread: https://bugs.python.org/issue41018 applies to this too.

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41014>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:46:06 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jul 2020 19:46:06 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594064766.16.0.29907869318.issue29778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Announcement post: https://mail.python.org/archives/list/security-announce at python.org/thread/C5RIXC2ZIML3NOEIOGFPA6ISGU5L2QXL/

CVE-2020-15523 is an invalid search path in Python 3.6 and later on 
Windows. It occurs during Py_Initialize() when the runtime attempts to 
pre-load python3.dll. If Py_SetPath() has been called, the expected 
location is not set, and locations elsewhere on the user's system will 
be searched.

This issue is not triggered when running python.exe. It only applies 
when CPython has been embedded in another application.

Issue: https://bugs.python.org/issue29778
Patch: https://github.com/python/cpython/pull/21297

The next patched releases will be: 3.9.0b5, 3.8.4, 3.7.9 (source only), 
3.6.12 (source only)

Other than applying the patch, applications may mitigate the 
vulnerability by explicitly calling LoadLibrary() on their copy of 
python3.dll before calling Py_Initialize(). Even with the patch applied, 
applications should include a copy of python3.dll alongside their main 
Python DLL.

Thanks to Eric Gantumur for detecting and reporting the issue to the 
Python Security Response Team.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:54:02 2020
From: report at bugs.python.org (Yann Dirson)
Date: Mon, 06 Jul 2020 19:54:02 +0000
Subject: [issue41222] Undocumented behaviour change of POpen.stdout.readine
 with bufsize=0 or =1
Message-ID: <1594065242.21.0.841046846995.issue41222@roundup.psfhosted.org>


New submission from Yann Dirson <yann at blade-group.com>:

On a POpen object created with bufsize=0, stdout.readline() does a buffered reading with python3, whereas in 2.7 it did char-by-char reading.  See attached example.

As a result, a poll including the stdout object suffers a behaviour change when stdout is ready for writing and there is more than one line of data available.  In both cases we get notified by poll() that data is available on the fd and we can stdout.readline() and get back to our polling loop.  Then:

* with python2 poll() then returns immediately and stdout.readline() will then return the next line

* with python3 poll() now blocks

Running the attached example under strace reveals the underlying difference:

 write(4, "go\n", 3)                     = 3
 poll([{fd=5, events=POLLIN|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "x", 1)                         = 1
-read(5, "\n", 1)                        = 1
-fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}) = 0
+read(5, "xxxxxxxxxxxx\nyyyyyyyyyyyyyyy\naaa"..., 8192) = 74
 write(1, ">xxxxxxxxxxxx\n", 14)         = 14


We can see a buffered read, which explains the behaviour difference.

Changing to bufsize=1, strace does not show a difference here.

This is especially troubling, as the first note in https://docs.python.org/3/library/io.html#class-hierarchy mentions that even in buffered mode there is an unoptimized readline() implementation.

----------
components: IO
files: testproc-unbuffered.py
messages: 373165
nosy: yann
priority: normal
severity: normal
status: open
title: Undocumented behaviour change of POpen.stdout.readine with bufsize=0 or =1
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49299/testproc-unbuffered.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41222>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:56:10 2020
From: report at bugs.python.org (Bruce Merry)
Date: Mon, 06 Jul 2020 19:56:10 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1594065370.61.0.780677906375.issue32528@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

FYI this has just bitten me after updating my OS to one that ships Python 3.8. It is code that was written with asyncio cancellation in mind and which expected CancelledError to be caught with "except Exception" (the exception block unwound incomplete operations before re-raising the exception).

It's obviously too late to do anything about Python 3.8, but I'm mentioning this as a data point in support of having a deprecation period if similar changes are made in future.

On the plus side, while fixing up my code and checking all instances of "except Exception" I found some places where this change did fix latent cancellation bugs. So I'm happy with the change, just a little unhappy that it came as a surprise.

----------
nosy: +bmerry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:00:05 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 06 Jul 2020 20:00:05 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1594065605.77.0.655514489322.issue39375@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:02:26 2020
From: report at bugs.python.org (Manuel Jacob)
Date: Mon, 06 Jul 2020 20:02:26 +0000
Subject: [issue41221] Output of print() might get truncated in unbuffered mode
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594065746.63.0.540957602862.issue41221@roundup.psfhosted.org>


Manuel Jacob <me at manueljacob.de> added the comment:

2147479552 is the 0x7ffff000 bytes limit documented for write() on Linux (source: https://man7.org/linux/man-pages/man2/write.2.html). The limit could be even smaller in other circumstances or other systems.

I?m adding Victor Stinner to the nosy list, as he added the code limiting writes to the console on Windows in e0daff1c61e323d2a39dd8241de67082d1f10fd7, and he might have an opinion on the topic.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:18:05 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 20:18:05 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1594066685.91.0.0727306792811.issue39562@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> As the changes here has been released maybe you want to reclose and marked https://bugs.python.org/issue41218 as blocker it should also be fixed by
https://github.com/python/cpython/pull/21357

Thanks for the heads up, Matthias!

Yes, I think is the best thing to do. For some reason, I thought this was not still released :(

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:18:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 20:18:20 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594066700.54.0.180895845174.issue41218@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +lukasz.langa
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:24:04 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 06 Jul 2020 20:24:04 +0000
Subject: [issue41014] warning: 'sqlite3_trace' is deprecated
In-Reply-To: <1592436367.99.0.294210468626.issue41014@roundup.psfhosted.org>
Message-ID: <1594067044.14.0.55911966079.issue41014@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree, this is a "feature" of the SQLite headers as shipped by Apple.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: enhancement -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41014>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:26:40 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jul 2020 20:26:40 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594067200.58.0.980538022799.issue41207@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Sure. I'll submit patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:28:22 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 06 Jul 2020 20:28:22 +0000
Subject: [issue40742] Doc: Parallel build break audit table
In-Reply-To: <1590231407.13.0.794441624197.issue40742@roundup.psfhosted.org>
Message-ID: <1594067302.76.0.372174008881.issue40742@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset a103e73ce8d34e3af5f556ee9090ce89249d565e by Julien Palard in branch 'master':
bpo-40742: Doc: fix parallel build. (GH-21237)
https://github.com/python/cpython/commit/a103e73ce8d34e3af5f556ee9090ce89249d565e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40742>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:28:40 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 06 Jul 2020 20:28:40 +0000
Subject: [issue40742] Doc: Parallel build break audit table
In-Reply-To: <1590231407.13.0.794441624197.issue40742@roundup.psfhosted.org>
Message-ID: <1594067320.53.0.00021892365277.issue40742@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40742>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:53:00 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jul 2020 20:53:00 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594068780.83.0.995299435222.issue41207@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I learned the magical incantation to port commits from pypa/distutils to CPython:

```
cpython bugfix/41207-rewrite-filenotfound $ git -C ~/p/pypa/distutils format-patch HEAD~2 --stdout | git am --directory Lib                                
Applying: Add test for spawn when exe is missing. Ref pypa/distutils#3.
Applying: Replace OSError with DistutilsExecError. Fixes pypa/distutils#3 and pypa/setuptools#2228 and bpo-41207.
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:56:18 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jul 2020 20:56:18 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594068978.95.0.36593742768.issue41207@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +20504
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:02:57 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 06 Jul 2020 21:02:57 +0000
Subject: [issue41217] Obsolete note for default asyncio event loop on Windows
In-Reply-To: <1594023051.16.0.859268804549.issue41217@roundup.psfhosted.org>
Message-ID: <1594069377.57.0.757246864776.issue41217@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +20505
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21360

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41217>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:04:49 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Jul 2020 21:04:49 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594063879.71.0.24160134831.issue41215@roundup.psfhosted.org>
Message-ID: <FE7A8924-A251-4E1C-BDD8-40D6780097F1@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I also tested xlC v16, and then it just hung, for hours - while all of you were being more productive. 

I?ll kickoff my bot again, and see how it goes. 

Sent from my iPhone

> On 6 Jul 2020, at 21:31, miss-islington <report at bugs.python.org> wrote:
> 
> ?
> miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:
> 
> 
> New changeset 1ac0cbca369f16f9191833dd54536482fb141a98 by Pablo Galindo in branch 'master':
> bpo-41215: Don't use NULL by default in the PEG parser keyword list (GH-21355)
> https://github.com/python/cpython/commit/1ac0cbca369f16f9191833dd54536482fb141a98
> 
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:07:54 2020
From: report at bugs.python.org (Ian Jacob Bertolacci)
Date: Mon, 06 Jul 2020 21:07:54 +0000
Subject: [issue35786] get_lock() method is not present for Values created
 using multiprocessing.Manager()
In-Reply-To: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org>
Message-ID: <1594069674.34.0.136710271215.issue35786@roundup.psfhosted.org>


Ian Jacob Bertolacci <ian.bertolacci at gmail.com> added the comment:

What's being done about this?
I would say this is less "misleading documentation" and more "incorrect implementation"

There is also not an obvious temporary work-around.

----------
nosy: +IanBertolacci

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35786>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:12:19 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jul 2020 21:12:19 +0000
Subject: [issue35786] get_lock() method is not present for Values created
 using multiprocessing.Manager()
In-Reply-To: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org>
Message-ID: <1594069939.54.0.112590155073.issue35786@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
components:  -Windows
nosy:  -steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35786>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:19:56 2020
From: report at bugs.python.org (jakirkham)
Date: Mon, 06 Jul 2020 21:19:56 +0000
Subject: [issue41223] `object`-backed `memoryview`'s `tolist` errors
Message-ID: <1594070396.59.0.711560769808.issue41223@roundup.psfhosted.org>


New submission from jakirkham <jakirkham at gmail.com>:

When working with an `object`-backed `memoryview`, it seems we are unable to coerce it to a `list`. This would be useful as it would provide a way to get the underlying `object`'s into something a bit easier to work with.

```
In [1]: import numpy                                                            

In [2]: a = numpy.array(["abc", "def", "ghi"], dtype=object)                    

In [3]: m = memoryview(a)                                                       

In [4]: m.tolist()                                                              
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
<ipython-input-4-42400a31add8> in <module>
----> 1 m.tolist()

NotImplementedError: memoryview: format O not supported
```

----------
messages: 373175
nosy: jakirkham
priority: normal
severity: normal
status: open
title: `object`-backed `memoryview`'s `tolist` errors
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41223>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:27:01 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 06 Jul 2020 21:27:01 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594070821.46.0.492971979491.issue41218@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset bd46174a5a09a54e5ae1077909f923f56a7cf710 by Matthias Bussonnier in branch 'master':
bpo-41218: Only mark async code with CO_COROUTINE. (#21357)
https://github.com/python/cpython/commit/bd46174a5a09a54e5ae1077909f923f56a7cf710


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:27:10 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 21:27:10 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594070830.37.0.51717229836.issue41218@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20506
pull_request: https://github.com/python/cpython/pull/21361

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:29:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 21:29:20 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594070960.57.0.0438899792456.issue41218@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal
nosy_count: 3.0 -> 4.0
pull_requests: +20507
pull_request: https://github.com/python/cpython/pull/21362

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:32:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 21:32:37 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594071157.52.0.750548971894.issue41218@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +20508
pull_request: https://github.com/python/cpython/pull/21363

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:33:04 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 06 Jul 2020 21:33:04 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594071184.13.0.240817737898.issue22239@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks for posting this, Mike.

> Vague claims of "framework X is faster because it's async" appear, impossible to confirm as it is unknown how much of their performance gains come from the "async" aspect and how much of it is that they happened to rewrite a new framework from scratch in a completely different way (hint: it's the latter).

These kind of claims are not specific to async vs. sync. They are all over the place for every two pieces of comparable technologies. While novice users might base their technology choice purely on such benchmarks, it's less of an issue for startups/tech companies.

That said, I agree with most of your points so far.

> The asyncpg project, one of the few asyncio database drivers that exists, notes in its FAQ "asyncpg uses asynchronous execution model and API, which is fundamentally incompatible with SQLAlchemy" [2], yet we know this is not true  because SQLAlchemy works just fine with gevent and eventlet, with no architectural changes at all.

But it is true. Making asynchronous network requests in asyncio requires async/await or using callbacks and it's not possible to do them, say, from __getattr__ (you mention this yourself).  This is what that particular comment is about, nothing more. Using gevent and eventlet as examples in this particular context isn't helping you. Apologies for nitpicking, I know it's not the point of this discussion.

> A day later, someone took the same idea and got Flask to work in an asyncio event loop at [5].  The general idea of using greenlet in this way is also present at [6], so I won't be patenting this idea today as oremanj can claim prior art.

Yes, this approach definitely works and I even did that in production myself a few years ago with https://github.com/1st1/greenio (it's terribly outdated now).

> The recipe is simple and so far appears to be very effective.

This recipe was one of the reasons why I added `loop.set_task_factory` method to the spec, so that it's possible to implement this in an *existing* event loop like uvloop. But ultimately asyncio is flexible enough to let users use their own event loop which can be compatible with greenlets among other improvements.

Ultimately, asyncio will probably never ship with greenlets integration enabled by default, but we should definitely make it possible (if there are some limitations now).  It doesn't seem to me that nested event loops are needed for this, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:34:38 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 21:34:38 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594071278.17.0.196213400304.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Michael, could you check the latest master and 3.9 HEAD? If you don;t see the problem anymore, we can close this issue :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:38:41 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jul 2020 21:38:41 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594071521.37.0.266101887387.issue41215@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Pablo, on second thought, should we maybe change the assertion to `assert(name_len > 0)`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:44:24 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 21:44:24 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594071864.33.0.746640959771.issue41218@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 41db8ffc59566b8552f9cce4452ee8afad00aa63 by Miss Islington (bot) in branch '3.8':
bpo-41218: Only mark async code with CO_COROUTINE. (GH-21357)
https://github.com/python/cpython/commit/41db8ffc59566b8552f9cce4452ee8afad00aa63


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:47:22 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 06 Jul 2020 21:47:22 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594072042.66.0.943730657949.issue41202@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The idiomatic way:


async def main():
  loop = asyncio.get_running_loop()
  loop.set_exception_handler(...)
  # other code

asyncio.run(main())

We don't want to add new arguments to asyncio.run as there would be too many.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:48:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 21:48:17 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594072097.88.0.249955101848.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Pablo, on second thought, should we maybe change the assertion to `assert(name_len > 0)`?

Yup, although not sure how that can happen (but I agree that's the point of assertions *wink*) Can you prepare a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 17:58:53 2020
From: report at bugs.python.org (mike bayer)
Date: Mon, 06 Jul 2020 21:58:53 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594072733.66.0.687310397642.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

>  This recipe was one of the reasons why I added `loop.set_task_factory` method to the spec, so that it's possible to implement this in an *existing* event loop like uvloop. But ultimately asyncio is flexible enough to let users use their own event loop which can be compatible with greenlets among other improvements.

Right, when I sought to look at this, I know that my users want to use the regular event loop in asyncio or whatever system they are using.


> Ultimately, asyncio will probably never ship with greenlets integration enabled by default, but we should definitely make it possible (if there are some limitations now).  It doesn't seem to me that nested event loops are needed for this, right?

So right, the approach I came up with does not need nested event loops and it's my vague understanding that nesting event loops is more difficult to debug, because you have these two separate loops handing off to each other.    

What is most striking about my recipe is that it never even leaves the default event loop.  Originally my first iteration when I was trying to get it working, I had a separate thread going on, as it seemed intuitive that "of course you need a thread to bridge async and sync code" but then I erased the "Thread()" part around it and then it just worked anyway.   Like it's simple enough that shipping this as a third party library is almost not even worth it, you can just drop this in wherever.   If different libraries had their own drop-in of this, they would even work together.   greenlet is really like totally cheating.  

the philosophical thing here is, usually in my many twitter debates on the subject, folks get into how they like the explicit async and await keywords and they like that IO is explicit.   So I'm seeking to keep these people happy and give then "async def execute(sql)", and use an async DB driver, but then the library that these folks are using is internally not actually explicit IO.  But they don't have to see that, I've done all the work of the "implicit IO" stuff and in a library it's not the same kind of problem anyway.     I think this is a really critical technique to have so that libraries that mediate between a user-facing facade and TCP based backends no longer have to make a hard choice about if they are to support sync vs. async (or async with an optional sync facade around it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:04:36 2020
From: report at bugs.python.org (Brett Hannigan)
Date: Mon, 06 Jul 2020 22:04:36 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1594073076.36.0.0376044207864.issue41177@roundup.psfhosted.org>


Brett Hannigan <brett.hannigan at gmail.com> added the comment:

O.K. CLA is now signed and if I check on the "check-yourself" with my github user it is showing that I have signed it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:11:18 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Mon, 06 Jul 2020 22:11:18 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594073478.6.0.0822266273665.issue40360@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

Looking at the suggested successor tools (redbaron, libCST, parso, awpa) ... all of them appear to use some variant of pgen2. But at some point Python will be using a PEG approach (PEP 617), and therefor the pgen2 approach apparently won't work.

For a number of projects, it's important to have a parse tree that contains all the "whitespace" information (indent, dedent, comment, newline, etc.) As far as I can tell, the new PEG parser won't provide that, and it seems that none of the successor tools will be able to handle future versions of Python syntax.

So, three questions:
1. Am I right that all proposed replacements (redbaron, libCST, parso, awpa) use some variation of the LL(1) and therefore will have trouble in the future?
2. Are there any plans (either part of the core development or as a project) for one of these replacements that is PEG-based? (Or a new project?)
3. Is Lib/ast.py going to continue being supported? (I infer that it will, with the change from LL(1) to PEG being mostly transparent - https://mail.python.org/archives/list/python-dev at python.org/thread/HOZ2RI3FXUEMAT4XAX4UHFN4PKG5J5GR/#4D3B2NM2JMV2UKIT6EV5Q2A6XK2HXDEH )

If Lib/ast.py continues to be supported, I think I can see a way of providing functionality similar to lib2to3 (in terms of an AST-ish thing with "whitespace" from the source, sufficient for tools such as yapf, black, pykythe, pytype, mypy, etc.) as a kind of wrapper to ast.py. 
I suppose I should discuss this idea on python-dev? Is there an ongoing discussion? (I couldn't find any but might have been using the wrong search terms)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:13:27 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 06 Jul 2020 22:13:27 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594073607.51.0.640576607567.issue22239@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I think this is a really critical technique to have so that libraries that mediate between a user-facing facade and TCP based backends no longer have to make a hard choice about if they are to support sync vs. async (or async with an optional sync facade around it).

If this works for such a big and elaborate framework as SQLA, we can definitely highlight this as a valid approach and even add a link to a blog post from the docs. We'll need to add an asyncio specific FAQ page for that or something similar.

Another approach, which would probably be a nonstarter for SQLA, is to use async/await for literally everything internally, and provide a tiny synchronous facade on top.  Funny thing you don't even need an event loop for that, just the basic understanding of how coroutines work internally.  I used this to create the edgedb-python package which has both sync and async first-class support with one code base.  Sync is even faster there in simple throughput benchmarks (as expected).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:21:11 2020
From: report at bugs.python.org (Aivar Annamaa)
Date: Mon, 06 Jul 2020 22:21:11 +0000
Subject: [issue39107] Upgrade tcl/tk to 8.6.10 (Windows and maxOS)
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1594074071.89.0.0661741015379.issue39107@roundup.psfhosted.org>


Aivar Annamaa <aivar.annamaa at gmail.com> added the comment:

According to the comments under https://github.com/python/cpython/pull/18982 there is no point in creating a PR, so I'll just share my experiences.

I was able to build current master with Tcl/Tk 8.6.10 both on Windows 10 (64-bit) and on macOS Catalina. I ran the tests on Windows and no Tkinter-related tests failed. I tested it manually on both platforms by poking around in IDLE and Thonny IDE and saw no (big) issues. (The only regression I saw in Thonny was Toplevel tooltips gaining a title bar, but I could solve it by adding a "wm_overrideredirect(1)"). 

One of the new features on macOS -- support for dark mode -- looked nice. Half-baked emoji support had not regressed at least.

I really hope you'll find time to include Tk 8.6.10 in the last beta of Python 3.9!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:23:13 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jul 2020 22:23:13 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594074193.79.0.150309812871.issue41215@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +20509
pull_request: https://github.com/python/cpython/pull/21364

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:26:27 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jul 2020 22:26:27 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594074387.31.0.678114626378.issue41215@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

> Can you prepare a PR?

Done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:30:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 22:30:17 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594074617.73.0.253293338881.issue41218@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset c2c1f1f906cdeb40576880d4b6a4f8fcbc016eb8 by Pablo Galindo in branch 'master':
bpo-41218: Improve the test cases for test_compile_top_level_await_no_coro (GH-21363)
https://github.com/python/cpython/commit/c2c1f1f906cdeb40576880d4b6a4f8fcbc016eb8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:30:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 22:30:23 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594074623.7.0.36016701454.issue41218@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 6488a4a3c9790040059fc5d293e518f193daac8d by Pablo Galindo in branch '3.9':
[3.9] bpo-41218: Only mark async code with CO_COROUTINE. (GH-21357) (GH-21362)
https://github.com/python/cpython/commit/6488a4a3c9790040059fc5d293e518f193daac8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:30:56 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 22:30:56 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594074656.07.0.261518055843.issue41218@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20511
pull_request: https://github.com/python/cpython/pull/21366

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:30:48 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 22:30:48 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594074648.29.0.0779542354128.issue41218@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20510
pull_request: https://github.com/python/cpython/pull/21365

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:31:29 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jul 2020 22:31:29 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594074689.19.0.225642471653.issue41218@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:42:34 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 22:42:34 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594075354.81.0.105374774113.issue41215@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20512
pull_request: https://github.com/python/cpython/pull/21367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:42:30 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jul 2020 22:42:30 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594075350.36.0.894694698629.issue41215@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:


New changeset 782f44b8fb07ec33cee148b2b6b4cf53024fe0cd by Lysandros Nikolaou in branch 'master':
bpo-41215: Make assertion in the new parser more strict (GH-21364)
https://github.com/python/cpython/commit/782f44b8fb07ec33cee148b2b6b4cf53024fe0cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:28:25 2020
From: report at bugs.python.org (mike bayer)
Date: Mon, 06 Jul 2020 23:28:25 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594078105.79.0.649703631221.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

yes so if you have async/await all internal, are you saying you can make that work for synchronous code *without* running the event loop?  that is, some kind of container that just does the right thing?  my concern with that would still be performance.    When asyncio was based on yield and exception throws, that was a lot of overhead to add to functions and that was what my performance testing some years back showed.   w/ async/await I'm sure things have been optimized, but in general when i have function a() -> b() -> c(), I am trying to iron as much Python overhead as I possibly can out of that and I'd be concerned that the machinery to work through async/await would add latency.   additionally if it was async/await internally but then i need to access the majority of Python DBAPIs that are sync, I need a thread pool anyway, right?  which is also another big barrier to jump over.

It seems you were involved with urllib3's approach to use a code rewriter rather than a runtime approach based on the discussion at https://github.com/urllib3/urllib3/issues/1323 , but it's not clear if Python 2 compatibility was the only factor or if the concern of "writing a giant shim" was also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:30:53 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 23:30:53 +0000
Subject: [issue41218] PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set
 .CO_COROUTINE falg.
In-Reply-To: <1594047652.43.0.575402047323.issue41218@roundup.psfhosted.org>
Message-ID: <1594078253.34.0.338844762578.issue41218@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b71ff9a5b6e60ee1209a04d2e0e58d9a2e341db3 by Miss Islington (bot) in branch '3.8':
bpo-41218: Improve the test cases for test_compile_top_level_await_no_coro (GH-21363)
https://github.com/python/cpython/commit/b71ff9a5b6e60ee1209a04d2e0e58d9a2e341db3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41218>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:34:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2020 23:34:45 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594078485.42.0.310132238811.issue41220@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What is the given example trying to accomplish?  It looks like every possible input list would be cached using just the first element of the list.  Would cached_func([10, 20, 30]) and cached_func([10, 11, 12]) return the same sum?  If not, why would that be desireable?

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:35:13 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jul 2020 23:35:13 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594078513.68.0.67978763826.issue41215@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset edeaf61b6827ab3a8673aff1fb7717917f08f003 by Miss Islington (bot) in branch '3.9':
bpo-41215: Make assertion in the new parser more strict (GH-21364)
https://github.com/python/cpython/commit/edeaf61b6827ab3a8673aff1fb7717917f08f003


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:39:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2020 23:39:09 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594078749.51.0.653133341755.issue41220@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373194

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:40:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2020 23:40:31 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594078831.49.0.590210790683.issue41220@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What is the given example trying to accomplish?  It looks like every possible input list would be cached using just the first element of the list.  Would cached_func([10, 20, 30]) and cached_func([10, 11, 12]) return the same sum?  If so, why would that be desirable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:44:13 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Jul 2020 23:44:13 +0000
Subject: [issue41219] Mimetypes doesn't support audio/webm
In-Reply-To: <1594054039.75.0.283470806341.issue41219@roundup.psfhosted.org>
Message-ID: <1594079053.02.0.409923911653.issue41219@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20513
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21368

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41219>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:47:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2020 23:47:44 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594079264.56.0.572032769641.issue41220@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>>> from functools import lru_cache
>>> def my_make_key(my_list):
...   return my_list[0]
...
>>> @lru_cache(128, make_key=my_make_key)
... def cached_func(my_list):
...   return sum(my_list)
...
>>> cached_func([10, 20, 30])
60
>>> cached_func([10, 11, 12]) # <-- Why would we want this to return 60?
60

This seems unsafe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:53:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2020 23:53:59 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594079639.22.0.00978174895142.issue41220@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373196

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:55:00 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 06 Jul 2020 23:55:00 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594079700.84.0.0316466894372.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

There's no python-dev discussion; if you want more feedback I recommend starting on python-ideas first (on either forum you may expect pushback because this is not about a proposed change to Python or its workflow).

The Lib/ast.py module will continue to be the official API for the standard AST. It is a simple wrapper around the builtin parser (at least in CPython -- I don't actually know to what extent other Python implementations support it, but they certainly *could*). And in 3.9 and later the AST is already being produced using the *new* parser.

We want to deprecate lib2to3 because nobody is interested in maintaining it., Having it in the stdlib, with its strict backwards compatibility requirements, makes it difficult to do a good job at updating it. This is why it's been forked repeatedly -- once forked, the owner of the fork can make changes easily, preserving the API perfectly (if so desired) and maintaining compatibility with older Python versions.

My own thoughts are that libraries like LibCST and parso have two sides: an API for the AST, and a way to parse source code into an AST. Usually the parsing API is incredibly simple -- e.g. a function to parse a file and another function to parse a string. And there's no reason for the AST API to change just because the parsing algorithm has changed.

Finally, we already have a (rough) Python implementation of the PEG parser too -- in fact it's included in Tools/peg_generator (and used to regenerate the metaparser). This reads the same grammar format (i.e. Grammar/python.gram) and generates Python code instead of C code to do the parsing. It's easy to retarget the tokenizer of the generated Python code.

So a decent way forward might be to pick one of the 3rd party libraries (perhaps parso, which is itself a fork of lib2to3 and what LibCST builds on) and update its parser to use a PEG parser generated using the PEG generator from Tools/peg_generator (which people are welcome to fork).

This might be a summer-of-code-sized project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:07:23 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Tue, 07 Jul 2020 00:07:23 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594080443.55.0.567111355433.issue41210@roundup.psfhosted.org>


Hiroshi Miura <miurahr at linux.com> added the comment:

>    Compression filters:
>            FILTER_LZMA1 (for use with FORMAT_ALONE)
>            FILTER_LZMA2 (for use with FORMAT_XZ and FORMAT_RAW)

I look into past discussion  BPO-6715 when lzma module proposed.
https://bugs.python.org/issue6715

There is an only comment about FORMAT_ALONE and LZMA1 here 
https://bugs.python.org/issue6715#msg92174

> .lzma is actually not a format. It is just the raw output of the LZMA1
> coder. XZ instead is a container format for the LZMA2 coder, which
probably means LZMA+some metadata.

It said FORMAT_ALONE decode .lzma archive which use LZMA1 as coder and FORMAT_XZ decode .xz archive which use LZMA2 as coder.
There are no discussion about FORMAT_RAW.

This indicate an opposite relation between two things.
FORMAT_ALONE should use with LZMA1.
FORMAT_XZ should use with LZMA2. 

FORMAT_RAW actually no limitation against LZMA1/2.

Here is another discussion about lzma_raw_encoder and LZMA1.
A xz/liblzma maintainer Lasse suggest lzma_raw_encoder is usable for LZMA1.
https://sourceforge.net/p/lzmautils/discussion/708858/thread/cd04b6ace0/#6050


I think we need fix the document.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:49:29 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 00:49:29 +0000
Subject: [issue41224] Document is_annotated() in the symtable module
Message-ID: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

The function is_annotated() in symtable is not documented. Am using this
opportunity to also add docstrings to the methods that didnot have them already.

----------
assignee: docs at python
components: Documentation
messages: 373200
nosy: docs at python, nanjekyejoannah
priority: normal
severity: normal
status: open
title: Document is_annotated() in the symtable module
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:50:27 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 00:50:27 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1594083027.79.0.895061603522.issue41224@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
title: Document is_annotated() in the symtable module -> Document is_annotate() in symtable and update doc strings

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:51:27 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 00:51:27 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1594083087.69.0.0397593446537.issue41224@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +20514
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21369

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:54:05 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 07 Jul 2020 00:54:05 +0000
Subject: [issue41217] Obsolete note for default asyncio event loop on Windows
In-Reply-To: <1594023051.16.0.859268804549.issue41217@roundup.psfhosted.org>
Message-ID: <1594083245.72.0.960525358925.issue41217@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41217>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:57:55 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 00:57:55 +0000
Subject: [issue41225] Add a test for get_id() in the symtable module
Message-ID: <1594083475.77.0.464939543595.issue41225@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

The method get_id() in the symtable module is implemented and documented but not tested.

----------
messages: 373201
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Add a test for get_id() in the symtable module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41225>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:59:39 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 00:59:39 +0000
Subject: [issue41225] Add a test for get_id() in the symtable module
In-Reply-To: <1594083475.77.0.464939543595.issue41225@roundup.psfhosted.org>
Message-ID: <1594083579.97.0.0122462777034.issue41225@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +20515
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21370

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41225>
_______________________________________

From report at bugs.python.org  Mon Jul  6 22:01:27 2020
From: report at bugs.python.org (jakirkham)
Date: Tue, 07 Jul 2020 02:01:27 +0000
Subject: [issue41226] Supporting `strides` in `memoryview.cast`
Message-ID: <1594087287.71.0.356108904694.issue41226@roundup.psfhosted.org>


New submission from jakirkham <jakirkham at gmail.com>:

Currently one can reshape a `memoryview` using `.cast(...)` like so...

```
In [1]: m = memoryview(b"abcdef")

In [2]: m2 = m.cast("B", (2, 3))
```

However it is not currently possible to specify the `strides` when reshaping the `memoryview`. This would be useful if the `memoryview` should be F-order or otherwise strided. To that end, syntax like this would be useful...

```
In [1]: m = memoryview(b"abcdef")

In [2]: m2 = m.cast("B", (2, 3), (1, 2))
```

----------
messages: 373202
nosy: jakirkham
priority: normal
severity: normal
status: open
title: Supporting `strides` in `memoryview.cast`
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41226>
_______________________________________

From report at bugs.python.org  Mon Jul  6 23:05:32 2020
From: report at bugs.python.org (Manuel Jacob)
Date: Tue, 07 Jul 2020 03:05:32 +0000
Subject: [issue41221] Output of print() might get truncated in unbuffered mode
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594091132.11.0.406400960283.issue41221@roundup.psfhosted.org>


Manuel Jacob <me at manueljacob.de> added the comment:

`io.TextIOWrapper.write()` returns the length of the passed string instead of the actually written number of characters.

% python -u -c "import sys; print(sys.stdout.write('x'*4294967296), file=sys.stderr)" | wc -c 
4294967296
2147479552

So the possibility "users of `io.TextIOWrapper` call `write()` until all characters have been written" would not be sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Mon Jul  6 23:33:36 2020
From: report at bugs.python.org (Faris Chugthai)
Date: Tue, 07 Jul 2020 03:33:36 +0000
Subject: [issue41227] minor typo in asyncio transport protocol
Message-ID: <1594092816.12.0.525496493671.issue41227@roundup.psfhosted.org>


New submission from Faris Chugthai <farischugthai at gmail.com>:

The penultimate sentence in asyncio transport.

> The subprocess is created by th loop.subprocess_exec() method:

Should be `created by the`.

The sentence can be seen here:

https://docs.python.org/3.10/library/asyncio-protocol.html?highlight=call_soon#loop-subprocess-exec-and-subprocessprotocol

----------
assignee: docs at python
components: Documentation, asyncio
messages: 373204
nosy: Faris Chugthai, asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: minor typo in asyncio transport protocol
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41227>
_______________________________________

From report at bugs.python.org  Mon Jul  6 23:47:42 2020
From: report at bugs.python.org (Mariatta)
Date: Tue, 07 Jul 2020 03:47:42 +0000
Subject: [issue41227] minor typo in asyncio transport protocol
In-Reply-To: <1594092816.12.0.525496493671.issue41227@roundup.psfhosted.org>
Message-ID: <1594093662.41.0.881098847159.issue41227@roundup.psfhosted.org>


Change by Mariatta <mariatta at python.org>:


----------
keywords: +easy, newcomer friendly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41227>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:39:40 2020
From: report at bugs.python.org (Raps Uk)
Date: Tue, 07 Jul 2020 05:39:40 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1594100380.56.0.0311857034129.issue36144@roundup.psfhosted.org>


Raps Uk <rapsuk at gmail.com> added the comment:

Taking the union of items() in Python 3 (viewitems() in Python 2.7) will also fail when values are unhashable objects (like lists, for example). Even if your values are hashable, since sets are semantically unordered, the behavior is undefined in regards to precedence. So don't do this:

>>> c = dict(a.items() | b.items())
This example demonstrates what happens when values are unhashable:

>>> x = {'a': []}
>>> y = {'b': []}
>>> dict(x.items() | y.items())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
Here's an example where y should have precedence, but instead the value from x is retained due to the arbitrary order of sets:

>>> x = {'a': 2}
>>> y = {'a': 1}
>>> dict(x.items() | y.items())
{'a': 2}

http://net-informations.com/python/ds/merge.htm

----------
nosy: +Raps Uk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:56:19 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Tue, 07 Jul 2020 05:56:19 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594101379.24.0.7265468666.issue41210@roundup.psfhosted.org>


Hiroshi Miura <miurahr at linux.com> added the comment:

I think FORMAT_RAW is only tested with LZMA2 in Lib/test/test_lzma.py Since no test is for LZMA1, then the document express FORMAT_RAW is for LZMA2.

I'd like to add tests against LZMA1 and change expression on the document.

----------
keywords: +patch
Added file: https://bugs.python.org/file49300/0001-lzma-support-LZMA1-with-FORMAT_RAW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:14:11 2020
From: report at bugs.python.org (Manuel Jacob)
Date: Tue, 07 Jul 2020 06:14:11 +0000
Subject: [issue41221] Output of print() might get truncated in unbuffered mode
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594102451.52.0.631842760723.issue41221@roundup.psfhosted.org>


Manuel Jacob <me at manueljacob.de> added the comment:

It?s possible to trigger the problem on Unix with much smaller sizes, e.g. by interrupting the write() with a signal handler (even if the signal handler doesn?t do anything). The following script starts a subprocess doing a 16MiB write and sends a signal, which is handled but is a no-op, after reading a bit from the pipe:

import signal
import subprocess
import sys

CHILD_PROCESS = '''
import signal, sys
signal.signal(signal.SIGINT, lambda *x: None)
written = sys.stdout.write('x' * 16777216)
print('written:', written, file=sys.stderr, flush=True)
'''

proc = subprocess.Popen(
    [sys.executable, '-u', '-c', CHILD_PROCESS],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
)
read = len(proc.stdout.read(1))
proc.send_signal(signal.SIGINT)
read += len(proc.stdout.read())
stdout, stderr = proc.communicate()
assert stdout == b''
print('stderr:', stderr)
assert read == 16777216, "read: {}".format(read)


% python3 test_interrupted_write.py
stderr: b'written: 16777216\n'
Traceback (most recent call last):
  File "test_interrupted_write.py", line 24, in <module>
    assert read == 16777216, "read: {}".format(read)
AssertionError: read: 69632

If I remove the '-u' that gets passed to the subprocess:

% python3 test_interrupted_write.py
stderr: b'written: 16777216\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:34:34 2020
From: report at bugs.python.org (Ma Lin)
Date: Tue, 07 Jul 2020 06:34:34 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594103674.0.0.952060713248.issue41210@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

There was a similar issue (issue21872).

When decompressing a lzma.FORMAT_ALONE format data, and it doesn't have the end marker (but has the correct "Uncompressed Size" in the .lzma header), sometimes the last one to dozens bytes can't be output.

issue21872 fixed the problem in `_lzmamodule.c`. But if liblzma strictly follows zlib's API (IMO it should), there should be no this problem.


I debugged your code with attached file `lzmabcj.bin`, when it output 12796 bytes, the output buffer still has 353 bytes space. So it seems to be a problem of liblzma.

IMHO, we first wait the reply from liblzma maintainer, if Lasse Collin thinks this is a bug, let us wait for the upstream fix. And I will report the issue21872 to see if he can fix the problem in upstream as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:37:39 2020
From: report at bugs.python.org (Nima Dini)
Date: Tue, 07 Jul 2020 06:37:39 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
Message-ID: <1594103859.96.0.219751919991.issue41228@roundup.psfhosted.org>


Change by Nima Dini <nima.dini at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, ndini
priority: normal
pull_requests: 20516
severity: normal
status: open
title: Fix the typo in the description of calendar.monthcalendar(year, month)
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Tue Jul  7 03:18:54 2020
From: report at bugs.python.org (Itay azolay)
Date: Tue, 07 Jul 2020 07:18:54 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594106334.2.0.469632434429.issue41220@roundup.psfhosted.org>


Itay azolay <itayazolay at gmail.com> added the comment:

Yes, you're right.
It's a bad example, I tried to simplify it, and I ended up oversimplifying it.
Real-life cases are of course more complicated.
What I wanted to accomplish, is very similar to the `key` argument in sorted/min/max/etc..
let my try and give you an example.

assume we have a complex data type, with a timestamp-signed attribute.
our single item will look as follows:
SingleItem = (unique_timestamp, <mutable_data_structure> )
now assume we have a function "extensive_computation"

def extensive_computation(items: List[SingleItem]):
  # very hard work
  sleep(60)

As developer, I know that the every item has unique timestamp.
So for a list of N timestamp, when they are the same, the result of the computation will be the same.

def item_cache_key(items: List[SingleItem]):
  return (timestamp for timestamp, data in items)

I would like to then create:

@lru_cache(128, key=item_cache_key):
def cache_extensive_computation(items):
  extensive_computation(items)

Does that makes more sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Tue Jul  7 04:21:51 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Tue, 07 Jul 2020 08:21:51 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594110111.53.0.0404860811248.issue41210@roundup.psfhosted.org>


Change by Hiroshi Miura <miurahr at linux.com>:


Added file: https://bugs.python.org/file49301/0001-lzma-support-LZMA1-with-FORMAT_RAW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Tue Jul  7 04:30:28 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Tue, 07 Jul 2020 08:30:28 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594110628.24.0.787100626118.issue41210@roundup.psfhosted.org>


Hiroshi Miura <miurahr at linux.com> added the comment:

Thank you for information about similar problem.

This problem is observed and reported on 7-zip library project, https://github.com/miurahr/py7zr/issues/178.
py7zr heavily depend on lzma FORMAT_RAW interface.

Fortunately  7-zip container format has size database, then library can know output is enough or not.

In reported case, the library/caller become a state that all input data has send into decompressor,  but decompressor does not output anything.

I'd like to wait upstream reaction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Tue Jul  7 05:12:14 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 07 Jul 2020 09:12:14 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594071278.17.0.196213400304.issue41215@roundup.psfhosted.org>
Message-ID: <7bc9dc43-4fb0-af12-fe25-0d578a4e60f4@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I saw the mails last night and restarted my bot - it still fails.
Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
know asap.

Yes - expecting 3.8 and 3.7 to build, but want to be sure.

On 06/07/2020 23:34, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> Michael, could you check the latest master and 3.9 HEAD? If you don;t see the problem anymore, we can close this issue :)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Tue Jul  7 05:23:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jul 2020 09:23:27 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594113807.27.0.413581589757.issue41220@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks, I see what you're trying to do now:

1) Given a slow function 
2) that takes a complex argument 
   2a)  that includes a hashable unique identifier 
   2b)  and some unhashable data
3) Cache the function result using only the unique identifier

The lru_cache() currently can't be used directly because
all the function arguments must be hashable.

The proposed solution:
1) Write a helper function
   1a) that hash the same signature as the original function
   1b) that returns only the hashable unique identifier
2) With a single @decorator application, connect
   2a) the original function
   2b) the helper function
   2c) and the lru_cache logic


A few areas of concern come to mind:

* People have come to expect cached calls to be very cheap, but it is easy to write input transformations that aren't cheap (i.e. looping over all the inputs as in your example or converting entire mutable structures to immutable structures).

* While key-functions are relatively well understood, when we use them elsewhere key-functions only get called once per element.  Here, the lru_cache() would call the key function every time even if the arguments are identical.  This will be surprising to some users.

* The helper function signature needs exactly match the wrapped function.  Changes would need to be made in both places.

* It would be hard to debug if the helper function return values ever stop being unique.  For example, if the timestamps start getting rounded to the nearest second, they will sporadically become non-unique.

* The lru_cache signature makes it awkward to add more arguments.  That is why your examples had to explicitly specify a maxsize of 128 even though 128 is the default. 

* API simplicity was an early design goal.  Already, I made a mistake by accepting the "typed" argument which is almost never used but regularly causes confusion and affects learnability.

* The use case is predicated on having a large unhashable dataset accompanied by a hashable identifier that is assumed to be unique.  This probably isn't common enough to warrant an API extension.  

Out of curiosity, what are you doing now without the proposed extension?  

As a first try, I would likely write a dataclass to be explicit about the types and about which fields are used in hashing and equality testing:

    @dataclass(unsafe_hash=True)
    class ItemsList:
        unique_id: float
        data: dict = field(hash=False, compare=False)

I expect that dataclasses like this will emerge as the standard solution whenever people need a mapping or dict to work with keys that have a mix of hashable and unhashable components.  This will work with the lru_cache(), dict(), defaultdict(), ChainMap(), set(), frozenset(), etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Tue Jul  7 05:31:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 09:31:32 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594114292.43.0.892036511353.issue29778@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI this vulnerability is now tracked by:
https://python-security.readthedocs.io/vuln/pysetpath-python-dll-path.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jul  7 05:33:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 09:33:05 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594114385.31.0.715649765337.issue29778@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Steve: Python 3.5 is also vulnerable, no? This branch still gets security fixes, do you plan to backport the fix? I can do it if you are not available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jul  7 06:12:15 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 07 Jul 2020 10:12:15 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <7bc9dc43-4fb0-af12-fe25-0d578a4e60f4@felt.demon.nl>
Message-ID: <5d86bfe5-aedb-e40a-3c28-5cf5db8d26a2@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 07/07/2020 11:12, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> I saw the mails last night and restarted my bot - it still fails.
> Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
3.7, 3.8 and 3.9 built, master does not. Will provide more info on
master later.
> know asap.
>
> Yes - expecting 3.8 and 3.7 to build, but want to be sure.
>
> On 06/07/2020 23:34, Pablo Galindo Salgado wrote:
>> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>>
>> Michael, could you check the latest master and 3.9 HEAD? If you don;t see the problem anymore, we can close this issue :)
>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue41215>
>> _______________________________________
>>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Tue Jul  7 06:35:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 10:35:55 +0000
Subject: [issue41221] io.TextIOWrapper ignores silently partial write if
 buffer is unbuffered
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594118155.08.0.443951584362.issue41221@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

cc Antoine Pitrou who was involved in io module design.

Currently, the io.TextIOWrapper implementation doesn't handle partial write: it doesn't fully support an unbuffered 'buffer' object.

It should either handle partial write internally, or it should inject a buffered writer between itself (TextIOWrapper) and the unbuffered buffer so handling partial writes who be handled by the buffered writer.

The socket.socket class has a sendall() method which helps to handle such problem. In the io module, sometimes write() can do a partial write (unbuffered writer like FileIO), sometimes it doesn't (buffered writer like BufferedWriter).

== C implementation ==

Modules/_io/text.c. The _io_TextIOWrapper_write_impl() function puts the encoded string into an internal pending_bytes list. If needed, it calls flush(): _textiowrapper_writeflush().

The pseudo-code of _textiowrapper_writeflush() is to call "self.buffer.write(b)" where b is made of all "pending bytes". write() result is ignored: partial write is silently ignored.

== Python implementation ==

_pyio.TextIOWrapper.write() simply calls: "self.buffer.write(b)". It ignores partial write silently.

----------
nosy: +pitrou
title: Output of print() might get truncated in unbuffered mode -> io.TextIOWrapper ignores silently partial write if buffer is unbuffered

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Tue Jul  7 06:36:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 10:36:06 +0000
Subject: [issue41221] io.TextIOWrapper ignores silently partial write if
 buffer is unbuffered
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594118166.58.0.898241381303.issue41221@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +inada.naoki, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Tue Jul  7 06:45:45 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Jul 2020 10:45:45 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594118745.27.0.440556918429.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Master has to be something else then....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Tue Jul  7 07:11:44 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 11:11:44 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594120304.91.0.594236759048.issue41207@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6ae2780be0667a8dc52c4fb583171ec86067d700 by Jason R. Coombs in branch 'master':
bpo-41207 In distutils.spawn, rewrite FileNotFound (GH-21359)
https://github.com/python/cpython/commit/6ae2780be0667a8dc52c4fb583171ec86067d700


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Tue Jul  7 07:11:57 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 11:11:57 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594120317.11.0.708247595067.issue41207@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20517
pull_request: https://github.com/python/cpython/pull/21373

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Tue Jul  7 07:31:44 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 11:31:44 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594121504.64.0.610170995115.issue41207@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2c82628e9aa2af4b662e92e227618859675dd726 by Miss Islington (bot) in branch '3.9':
bpo-41207 In distutils.spawn, rewrite FileNotFound (GH-21359)
https://github.com/python/cpython/commit/2c82628e9aa2af4b662e92e227618859675dd726


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Tue Jul  7 07:58:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 11:58:53 +0000
Subject: [issue41207] distutils.command.build_ext raises FileNotFoundError
In-Reply-To: <1593825952.85.0.0742954618161.issue41207@roundup.psfhosted.org>
Message-ID: <1594123133.63.0.308326597644.issue41207@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close the issue since it's fixed. I also reset the priority.

----------
priority: release blocker -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41207>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:08:08 2020
From: report at bugs.python.org (JIanqiu Tao)
Date: Tue, 07 Jul 2020 12:08:08 +0000
Subject: [issue41229] Asynchronous generator memory leak
Message-ID: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>


New submission from JIanqiu Tao <zkonge at outlook.com>:

The resource used by asynchronous generator can't be released properly when works with "asend" method.

Besides, in Python 3.7-, a RuntimeError was raised when asyncio.run complete, but the message is puzzling:
  RuntimeError: can't send non-None value to a just-started coroutine

In Python 3.8+, No Exception showed.

Python3.5 unsupport yield in async function, so it seems no affect?

----------
components: Interpreter Core, asyncio
files: leak.py
messages: 373221
nosy: asvetlov, yselivanov, zkonge
priority: normal
severity: normal
status: open
title: Asynchronous generator memory leak
type: resource usage
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49302/leak.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:17:37 2020
From: report at bugs.python.org (Saumitra Verma)
Date: Tue, 07 Jul 2020 12:17:37 +0000
Subject: [issue41230] IDLE intellisense
Message-ID: <1594124257.05.0.294353928422.issue41230@roundup.psfhosted.org>


New submission from Saumitra Verma <saumitraverma04 at gmail.com>:

There should be a simple autocomplete(intellisense) in idle.

----------
assignee: terry.reedy
components: IDLE
messages: 373222
nosy: Saumitra Verma, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE intellisense
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41230>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:19:10 2020
From: report at bugs.python.org (Saumitra Verma)
Date: Tue, 07 Jul 2020 12:19:10 +0000
Subject: [issue41230] IDLE intellisense
In-Reply-To: <1594124257.05.0.294353928422.issue41230@roundup.psfhosted.org>
Message-ID: <1594124350.01.0.402047943912.issue41230@roundup.psfhosted.org>


Change by Saumitra Verma <saumitraverma04 at gmail.com>:


----------
versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41230>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:22:38 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 07 Jul 2020 12:22:38 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1594118745.27.0.440556918429.issue41215@roundup.psfhosted.org>
Message-ID: <61f2ff51-533a-ee11-a699-fa0c5b46340e@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Here is the stack trace - still during initialization: And in "ceval.c,
but dbx does not like how the 'h files are being used: line 941 and 659
lines don't match :(

(dbx) list
"object.h" has only 659 lines

Segmentation fault in _PyEval_EvalFrameDefault at line 941 in file
"../git/py39-3.10/Include/object.h" ($t1)
"object.h" has only 659 lines
(dbx) where
_PyEval_EvalFrameDefault(tstate = 0x3009c9d0, f = 0x00000017, throwflag
= 15), line 941 in "object.h"
_PyEval_EvalCode(tstate = 0x1001c454, _co = 0x3009c250, globals =
0x2ff20260, locals = 0x10324233, args = 0x100b2798, argcount = 44,
kwnames = 0x2ff20280, kwargs = 0x2228228f, kwcount = 0, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x00000003, globals = 0x2ff20340, locals
= 0x2ff202f0, args = 0x2004429c, argcount = 805945904, kwnames = (nil),
kwargs = 0x2ff202f0, kwcount = 0, kwstep = 2, defs = (nil), defcount =
0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)),
line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10110c74, globals = 0x200817a2, locals =
(nil), args = 0x30091598, argcount = 805901716, kws = 0x200817da,
kwcount = 537401128, defs = 0x30078f58, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
builtin___build_class__(self = 0x100b8bdc, args = (nil), nargs =
804389872, kwnames = 0x2004429c), line 222 in "bltinmodule.c"
cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x100d5e54, args = (nil),
nargsf = 805553488, kwnames = 0x3004658c), line 459 in "methodobject.c"
_PyEval_EvalFrameDefault(tstate = 0x300912d8, f = 0x30050c8c, throwflag
= 805485032), line 628 in "abstract.h"
_PyEval_EvalCode(tstate = 0x10110c74, _co = 0x3004abb8, globals =
0x30095fa8, locals = 0x3009d16c, args = 0x3009d168, argcount =
805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0,
kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x30092258, locals
= 0x2ff20680, args = 0x2004429c, argcount = 269191840, kwnames =
0x300550e0, kwargs = 0x2ff20680, kwcount = 1109926476, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10090ab0, globals = (nil), locals =
0xf0653ea8, args = 0xf0653ea8, argcount = 0, kws = 0x20082720, kwcount =
804390704, defs = 0x2228228f, defcount = 0, kwdefs = (nil), closure =
(nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x103a1274, globals = 0x103a155e, locals =
0x30099978), line 857 in "ceval.c"
builtin_exec_impl(module = 0x300912c4, source = 0x30050cb8, globals =
0x20060a78, locals = 0x00000002), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x100d58b4, args = 0x30050cb8, nargs = 0), line
371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0xffffffff, args = 0x30050b80,
nargsf = 804391008, kwnames = 0x2004429c), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0x1001e5cc, tuple = 0x20060a78, kwargs =
0x2ff208c0), line 249 in "call.c"
_PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args =
0x2ff20920, kwargs = 0x2004429c), line 265 in "call.c"
do_call_core(tstate = 0x00000002, func = 0x20026bc0, callargs =
0x2ff20990, kwdict = 0x3004abb8), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0xffffffff, f = 0x3004a070, throwflag
= 804391536), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x3005e9b0, _co = 0x30062290, globals = (nil),
locals = 0x20026020, args = 0x300922f8, argcount = 805331176, kwnames =
0x2ff20b30, kwargs = 0x422822cf, kwcount = 0, kwstep = 1, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8,
qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005dbac, stack = (nil), nargsf =
805553488, kwnames = 0x30040960), line 417 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x300921b8, throwflag
= 804392064), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x30087538, co = 0x3004a1b0, args =
0x2000af70, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x00000001, throwflag =
804392400), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x30042fcc, co = 0x30031176, args =
0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060a78, throwflag
= 804392736), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x000000e0, co = 0x0000009c, args =
0x3003c550, nargs = -528718917, globals = 0x3004abd8), line 40 in
"pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = (nil), throwflag =
804393264), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004ab90, co = 0x3004a7c8, args =
0x2ff210f0, nargs = 537150108, globals = 0x10073f98), line 40 in
"pycore_ceval.h"
object_vacall(tstate = 0x2005ec18, base = 0x20060a78, callable =
0x2ff21150, vargs = warning: Unable to access address 0x482822cf from core
(invalid char ptr (0x482822cf))), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = (nil), name = 0x20026138, ... =
0x3008e920, 0x3003c5c8, 0x0, 0x3003ade8, 0x3003ad28, 0x3003ad48), line
901 in "call.c"
import_find_and_load(tstate = 0x3003c5e8, abs_name = 0x3008e920), line
1765 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x100b7374,
globals = 0x300930f0, locals = (nil), fromlist = 0x10391910, level =
805307360), line 1885 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x100b7374, globals =
0x300930f0, locals = (nil), fromlist = 0x10391910, level = 805307360),
line 1885 in "import.c"
import_name(tstate = 0x100d5e54, f = (nil), name = 0x3003c550, fromlist
= 0x3004658c, level = 0x3004abd8), line 5234 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x300912d8, f = 0x30050c8c, throwflag
= 805485032), line 3120 in "ceval.c"
_PyEval_EvalCode(tstate = 0x30091190, _co = 0x3004abb8, globals =
0x3008ea28, locals = 0x3004642c, args = 0x30046428, argcount =
805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0,
kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x30090d48, locals
= 0x2ff21570, args = 0x2004429c, argcount = 269191840, kwnames =
0x300550e0, kwargs = 0x2ff21570, kwcount = -2111298996, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10090ab0, globals = (nil), locals =
0xf0653ea8, args = 0xf0653ea8, argcount = 0, kws = 0x20082720, kwcount =
804394528, defs = 0x222822cf, defcount = 0, kwdefs = (nil), closure =
(nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x103a1274, globals = 0x103a155e, locals =
0x300930f0), line 857 in "ceval.c"
builtin_exec_impl(module = 0x300912c4, source = 0x30050cb8, globals =
0x20060a78, locals = 0x00000002), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x100d58b4, args = 0x30050cb8, nargs = 0), line
371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0xffffffff, args = 0x30050b80,
nargsf = 804394832, kwnames = 0x2004429c), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0x2ff21870, tuple = 0x30003870, kwargs =
0x2ff217d0), line 249 in "call.c"
_PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args =
0x2ff21810, kwargs = 0x0000000c), line 265 in "call.c"
do_call_core(tstate = 0x00000002, func = 0x20026bc0, callargs =
0x2ff21880, kwdict = 0x3004abb8), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0xffffffff, f = 0x3004a070, throwflag
= 804395360), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x3005e9b0, _co = 0x30062290, globals = (nil),
locals = 0x20026020, args = 0x30090d20, argcount = 805331176, kwnames =
0x2ff21a20, kwargs = 0x422822cc, kwcount = 0, kwstep = 1, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8,
qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005d8bc, stack = (nil), nargsf =
805553488, kwnames = 0x30040960), line 417 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x300889d8, throwflag
= 804395888), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x30087478, co = 0x3004a1b0, args =
0x2000af70, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x00000001, throwflag =
804396224), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004289c, co = 0x30031176, args =
0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060a78, throwflag
= 804396560), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x000000e0, co = 0x0000009c, args =
0x3003c550, nargs = 0, globals = 0x3004abd8), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x102e59fc, f = (nil), throwflag =
804397088), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004ab90, co = 0x3004a7c8, args =
0x2ff21fe0, nargs = 537150108, globals = 0x10073f98), line 40 in
"pycore_ceval.h"
object_vacall(tstate = 0x2005ec18, base = 0x20060a78, callable =
0x2ff22040, vargs = warning: Unable to access address 0x482822cf from core
(invalid char ptr (0x482822cf))), line 58 in "abstract.h"
_PyObject_CallMethodIdObjArgs(obj = (nil), name = 0x20026138, ... =
0x3008d4f8, 0x3003c5c8, 0x0, 0x3003ade8, 0x3003ad28, 0x3003ad48), line
901 in "call.c"
import_find_and_load(tstate = 0x2003e4d0, abs_name = (nil)), line 1765
in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30085de8,
globals = (nil), locals = 0x103a18e0, fromlist = 0x200377b0, level =
804397472), line 1885 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30085de8, globals = (nil),
locals = 0x103a18e0, fromlist = 0x200377b0, level = 804397472), line
1885 in "import.c"
builtin___import__(self = 0x100bead4, args = 0x00000010, kwds =
0x2ff22210), line 280 in "bltinmodule.c"
cfunction_call(func = 0x20060a78, args = 0x3003c528, kwargs = (nil)),
line 537 in "methodobject.c"
_PyObject_MakeTpCall(tstate = (nil), callable = 0x2ff2234c, args =
0x2ff222f0, nargs = 673718991, keywords = 0x100bc874), line 197 in "call.c"
_PyObject_CallFunctionVa(tstate = 0xeda68055, callable = (nil), format =
warning: Unable to access address 0xdeadbeef from core
(invalid char ptr (0xdeadbeef)), va = (nil), is_size_t = 0), line 65592
in "abstract.h"
PyObject_CallFunction(callable = 0x3003c5c8, format = "OOOOi", ... =
0x3008d4f8, 0x30085e38, 0x30085e38, 0x3006af68, 0x0, 0x0), line 583 in
"call.c"
PyImport_Import(module_name = 0x2ff22530), line 2086 in "import.c"
PyImport_ImportModule(name = "\200A"), line 1482 in "import.c"
PyImport_ImportModuleNoBlock(name = "`"), line 1500 in "import.c"
_PyCodecRegistry_Init(), line 1547 in "codecs.c"
_PyCodec_Forget(encoding = warning: Unable to access address 0xeda68055
from core
(invalid char ptr (0xeda68055))), line 128 in "codecs.c"
init_stdio_encoding(tstate = 0x2ff22604), line 15996 in "unicodeobject.c"
init_fs_encoding(tstate = 0x20008168), line 16110 in "unicodeobject.c"
_PyUnicode_InitEncodings(tstate = 0x20001110), line 16126 in
"unicodeobject.c"
init_interp_main(tstate = 0x00000001), line 1016 in "pylifecycle.c"
pyinit_main(tstate = 0x20001110), line 1107 in "pylifecycle.c"
Py_InitializeFromConfig(config = (nil)), line 1151 in "pylifecycle.c"
pymain_init(args = 0xf066a338), line 66 in "main.c"
pymain_main(args = 0x00000001), line 694 in "main.c"
Py_BytesMain(argc = -559038737, argv = 0xdeadbeef), line 727 in "main.c"
python.main(argc = 0, argv = (nil)), line 15 in "python.c"
(dbx)

On 07/07/2020 12:45, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> Master has to be something else then....
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:51:48 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 07 Jul 2020 12:51:48 +0000
Subject: [issue41230] IDLE intellisense
In-Reply-To: <1594124257.05.0.294353928422.issue41230@roundup.psfhosted.org>
Message-ID: <1594126308.59.0.315871928713.issue41230@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

If I understand the issue correctly, such a feature already exists. Currently, the wait before showing the list of completions is 2 seconds (https://github.com/python/cpython/blob/master/Lib/idlelib/config-extensions.def#L7) though this can be changed in settings. It is not as advanced as you would find in other IDEs, though it generally does the job.

----------
nosy: +epaine
versions:  -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/issue41230>
_______________________________________

From report at bugs.python.org  Tue Jul  7 09:34:30 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jul 2020 13:34:30 +0000
Subject: [issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's
 new
In-Reply-To: <1593634040.83.0.8340731803.issue41191@roundup.psfhosted.org>
Message-ID: <1594128870.8.0.424062164825.issue41191@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
keywords: +patch
pull_requests: +20518
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21374

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41191>
_______________________________________

From report at bugs.python.org  Tue Jul  7 09:53:32 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2020 13:53:32 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1594130012.03.0.756046877697.issue41205@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@JD-Veiga: would you be willing to work on a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Tue Jul  7 10:01:34 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Tue, 07 Jul 2020 14:01:34 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1594130494.37.0.787000548881.issue1635741@roundup.psfhosted.org>


Change by mohamed koubaa <koubaa.m at gmail.com>:


----------
pull_requests: +20519
pull_request: https://github.com/python/cpython/pull/21371

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Jul  7 10:22:43 2020
From: report at bugs.python.org (tomaszdrozdz)
Date: Tue, 07 Jul 2020 14:22:43 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594131763.4.0.807620577192.issue41202@roundup.psfhosted.org>


tomaszdrozdz <tomasz.drozdz.1 at protonmail.com> added the comment:

https://docs.python.org/3/library/asyncio-eventloop.html#error-handling-api  

Here we can read:  

Application developers should typically use the high-level asyncio functions, such as asyncio.run(), and should rarely need to reference the loop object or call its methods. This section is intended mostly for authors of lower-level code, libraries, and frameworks, who need finer control over the event loop behavior.  


So as I understand this - I should not use  
asyncio.get_running_loop  
loop.set_exception_handler(...)  

Or maybe event loop should not be in "Low level api"  ???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:37:59 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Tue, 07 Jul 2020 15:37:59 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594136279.64.0.040388073513.issue22239@roundup.psfhosted.org>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:03:32 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 07 Jul 2020 16:03:32 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594137812.82.0.966965583995.issue41202@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I agree with Yuri.

Usually, you don't need overriding of the default exception handler.
Indeed, if you really need this low-level API I see nothing wrong with `asyncio.get_running_loop()` call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:08:25 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jul 2020 16:08:25 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594138105.18.0.969565976521.issue29778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Python 3.5 is also vulnerable, no? This branch still gets security fixes, do you plan to backport the fix?

You're right. I thought because the backport tag was gone on GitHub that it was EOL already.

I can do the backport.

----------
nosy: +larry
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:12:47 2020
From: report at bugs.python.org (Nima Dini)
Date: Tue, 07 Jul 2020 16:12:47 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
Message-ID: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>


New submission from Nima Dini <nima.dini at gmail.com>:

https://docs.python.org/3.10/library/calendar.html#calendar.monthcalendar

> days outside of the month a represented by zeros.

"a" needs to be changed to "are"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:19:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 16:19:24 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594138764.28.0.626929510194.issue39542@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond:
> PyTuple_Check() got slower across the board.  This is problematic because the principal use case for PyTuple_Check() is as a guard for various fast paths.

Raymond gave more context in this email:
https://mail.python.org/archives/list/python-dev at python.org/message/Q3YHYIKNUQH34FDEJRSLUP2MTYELFWY3/

As far as I know, only macOS is impacted by this performance regression (119 nsec => 152 nsec on a microbenchmark). On Windows and Linux, Python is built with LTO and PGO optimizations.

For example, the Python package provided by Fedora 32 is built with GCC 10 using LTO and PGO. Using GCC 10 and LTO, the PyTuple_Check() code is inlined even if PyType_GetFlags() is function call in PyType_HasFeature().

I didn't know that on macOS, LTO was not used. I created bpo-41181 to request to enable LTO on the macOS installer builder, but Ned Deily rejected the issue (read the issue for the rationale).

I dislike comparing performances when LTO and PGO optimizations are not used. LTO enables tons of optimizations and PGO makes benchmark results more reproducible.

One idea is to stop running benchmarks on macOS, and at least only run benchmarks on binaries built with LTO and PGO.

--

Raymond:
> The direct cause of the degradation is that the inlining of PyType_Check() didn't go so well ? commit 509dd90f4684e40af3105dd3e754fa4b9c1530c1.

I'm not sure the performance changed with this commit. IMHO it's more the commit 45ec5b99aefa54552947049086e87ec01bc2fc9a: bpo-40170 and GH-19378.

Background behind this change: see PEP 620 for the overall plan, see bpo-39573 and bpo-40170 to make PyObject and PyTypeObject structures opaque. The idea is to slowly move third party extension modules towards the stable ABI (PEP 384). Internally, CPython continues to access directly structure members.


> The original unreviewed commit (...)

GH-19378 was reviewed and approved by another core dev.

The impact of performance of these changes was taken in account, and that's why it was decided to add a new internal _PyType_HasFeature() function.

It wasn't noticed that PyTuple_Check() calls the public PyType_HasFeature() instead of the internal _PyType_HasFeature(). As I wrote, using LTO, the code is inlined anyway, so it's the same thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:28:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 16:28:52 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594139332.3.0.86974977414.issue39542@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Stefan Krah:
> Christian Heimes has expressed an interest (quite rudely) in unreviewed commits elsewhere.  I wonder if that applies to everyone regardless of employer.

I don't understand the relationship between this issue, Christian Heimes and making reviews mandatory or not.

As I wrote, the commit 45ec5b99aefa54552947049086e87ec01bc2fc9a was reviewed and approved by another core dev.

Stefan, please stop personal attack and stay at the technical level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:07:00 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Jul 2020 17:07:00 +0000
Subject: [issue41215] AIX: build fails for xlc/xlC since new PEG parser
In-Reply-To: <1593948683.77.0.741960073898.issue41215@roundup.psfhosted.org>
Message-ID: <1594141620.7.0.801551130907.issue41215@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Yeah, this looks like something else. I am closing this issue then

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41215>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:07:31 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jul 2020 17:07:31 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594141651.5.0.289272227005.issue29778@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20520
pull_request: https://github.com/python/cpython/pull/21377

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:29:15 2020
From: report at bugs.python.org (David Caro)
Date: Tue, 07 Jul 2020 17:29:15 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
Message-ID: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>


New submission from David Caro <cascaranuez at gmail.com>:

In version 3.2, bpo-8814 introduced copying the __annotations__ property from the wrapped function to the wrapper by default.

That would be the desired behavior when your wrapper function has the same signature than the function it wraps, but in some cases (for example, with the contextlib.asynccontextmanager function) the return value is different, and then the __annotations__ property will have invalid information:

In [2]: from contextlib import asynccontextmanager                                                                                                            

In [3]: @asynccontextmanager 
   ...: async def mytest() -> int: 
   ...:     return 1 
   ...:                                                                                                                                                       

In [4]: mytest.__annotations__                                                                                                                                
Out[4]: {'return': int}


I propose changing the behavior of wraps, to only assign the __annotations__ by default if there's no __annotations__ already in the wrapper function, that would fit most default cases, but would allow to preserve the __annotations__ of the wrapper function when the types are explicitly specified, allowing now to change the contextlib.asynccontextmanager function with the proper types (returning now an AsyncContextManager) and keep the __annotation__ valid.

I'll try to get a POC and attach to the issue, but please comment with your ideas too.

----------
components: Library (Lib)
messages: 373233
nosy: David Caro
priority: normal
severity: normal
status: open
title: Type annotations lost when using wraps by default
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/issue41231>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:53:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jul 2020 17:53:54 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594144434.3.0.59988005976.issue39542@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here are two timings for math.dist().  They were run with the production macOS builds from python.org:

$ python3.8 -m timeit -r 11 -s 'from math import dist' -s 'p=(1.1, 2.2); q=(1.7, 2.3)' 'dist(p, q)'
5000000 loops, best of 11: 58.4 nsec per loop

$ python3.9 -m timeit -r 11 -s 'from math import dist' -s 'p=(1.1, 2.2); q=(1.7, 2.3)' 'dist(p, q)'
5000000 loops, best of 11: 66.9 nsec per loop

The attached screen shot shows that the only change between the two versions is that the subclass check is inlined and fast in 3.8, but is an external function call in 3.9.

---- 3.8 subclass check -----------
    movq    8(%r12), %rax
    movl    $0, 32(%rsp)
    testb   $4, 171(%rax)
    je  L779

---- 3.9 subclass check -----------

    movq    8(%r12), %rdi
    call    _PyType_GetFlags
    movl    $0, 32(%rsp)
    testl   $67108864, %eax
    je  L856

The C code for math.dist() is unchanged between 3.8 and 3.9.  Both use PyTuple_Check().

This isn't unique.  Every single PyTuple_Check() is the similarly affected (approx. 225 occurrences).  Presumably, this affects other type checks as well.

----------
Added file: https://bugs.python.org/file49303/Screen Shot 2020-07-07 at 10.40.52 AM.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:55:30 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jul 2020 17:55:30 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594144530.12.0.624871343109.issue39542@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Serhiy, do you have any insights to offer?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:00:05 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Tue, 07 Jul 2020 18:00:05 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1594144805.98.0.654011162451.issue1635741@roundup.psfhosted.org>


Change by mohamed koubaa <koubaa.m at gmail.com>:


----------
pull_requests: +20521
pull_request: https://github.com/python/cpython/pull/21375

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:20:11 2020
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 07 Jul 2020 18:20:11 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594146011.67.0.0886765205895.issue39542@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

A brief note for Victor that *nothing* was directed against him. On
the contrary, msg372995 was supporting him in case the commit had
actually been unreviewed, which it apparently wasn't. Sorry for
jumping on the bandwagon there.


> PEP 620 for the overall plan.

This one I have some trouble with.  It cites PyPy as a bottleneck, but
IIRC Armin Rigo was on record saying that such changes would not help
PyPy, and he would come up with a counter proposal. Has this changed?

It is also a bit unusual that the PEP is in draft status but a lot
of things are already committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:21:46 2020
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 07 Jul 2020 18:21:46 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594146106.04.0.758829577428.issue39542@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

s/PyPy as a bottleneck/the C-API as a bottle neck for PyPy/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:37:11 2020
From: report at bugs.python.org (Terry Davis)
Date: Tue, 07 Jul 2020 18:37:11 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
In-Reply-To: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>
Message-ID: <1594147031.9.0.239475190125.issue41231@roundup.psfhosted.org>


Terry Davis <terry.y.davis at gmail.com> added the comment:

I don't understand this use-case, but would it make sense to `ChainMap` the wrapper's __annotations__ on top of the wrapped __annotations__?

----------
nosy: +Terry Davis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41231>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:37:19 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jul 2020 18:37:19 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594147039.64.0.346391564559.issue39542@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Victor, is there any reason PyType_GetFlags() can't be converted to a macro or an inlined function?  That seems like a simple and robust fix that won't get in the way of anything else you're doing.

We shouldn't disregard macOS timings. It is an important platform ?dominant in data science, dominant among most of my clients, and dominant among the core developers at the last sprint.

None of the inlining should depend on LTO and PGO.  That is fragile and will create hard-to-explain variations between builds (even consecutive builds on the same platform).  Third-party extensions, SO and DLL files won't benefit from that.  Also, it makes it difficult to individually optimize and analyze a function without a costly rebuild at every step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:20:11 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 07 Jul 2020 19:20:11 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594149611.1.0.756942144967.issue22239@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Yeah, writing a trivial "event loop" to drive actually-synchronous code is easy. Try it out:

-----

async def f():
    print("hi from f()")
    await g()

async def g():
    print("hi from g()")

# This is our event loop:
coro = f()
try:
    coro.send(None)
except StopIteration:
    pass

-----

I guess there's technically some overhead, but it's tiny.

I think dropping 'await' syntax has two major downsides:

Downside 1: 'await' shows you where context switches can happen: As we know, writing correct thread-safe code is mind-bendingly hard, because data can change underneath your feet at any moment. With async/await, things are much easier to reason about, because any span of code that doesn't contain an 'await' is automatically atomic:

---
async def task1():
    # These two assignments happen atomically, so it's impossible for
    # another task to see 'someobj' in an inconsistent state.
    someobj.a = 1
    someobj.b = 2
---

This applies to all basic operations like __getitem__ and __setitem__, arithmetic, etc. -- in the async/await world, any combination of these is automatically atomic.

With greenlets OTOH, it becomes possible for another task to observe someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally invoked an await_(). Any operation can potentially invoke a context switch. So debugging greenlets code is roughly as hard as debugging full-on multithreaded code, and much harder than debugging async/await code.

This first downside has been widely discussed (e.g. Glyph's "unyielding" blog post), but I think the other downside is more important:

- 'await' shows where cancellation can happen: Synchronous libraries don't have a concept of cancellation. OTOH async libraries *are* expected to handle cancellation cleanly and correctly. This is *not* trivial. With your sqlalchemy+greenlets code, you've introduced probably hundreds of extra unwinding paths that you've never tested or probably even thought about. How confident are you that they all unwind correctly (e.g. without corrupting sqlalchemy's internal state)? How do you plan to even find them, given that you can't see the cancellation points in your code? How can your users tell which operations could raise a cancelled exception?

AFAICT you can't reasonably build systems that handle cancellation correctly without some explicit mechanism to track where the cancellation can happen. There's a ton of prior art here and you see this conclusion over and over.

tl;dr: I think switching from async/await -> greenlets would make it much easier to write programs that are 90% correct, and much harder to write programs that are 100% correct. That might be a good tradeoff in some situations, but it's a lot more complicated than it seems.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:37:37 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 07 Jul 2020 19:37:37 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594150657.56.0.468253289426.issue22239@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Yeah, writing a trivial "event loop" to drive actually-synchronous code is easy. Try it out:

This is exactly the approach I used in edgedb-python.

> I guess there's technically some overhead, but it's tiny.

Correct, the overhead isn't even detectable in microbenchmarks. In most async programs regular function calls dominate awaits by a few factors of magnitude.

> I think dropping 'await' syntax has two major downsides:

For the extra context, in the case of using this approach for something like edgedb-python these downsides don't really apply, because we're adapting async/await implementation to be sync. The async/await code can handle cancellation etc. whereas the sync code only needs to support the general protocol parsing flow. FWIW I don't think it would be possible to apply my approach to SQLA without a very invasive rewrite, which isn't probably worth it.

> tl;dr: I think switching from async/await -> greenlets would make it much easier to write programs that are 90% correct, and much harder to write programs that are 100% correct. That might be a good tradeoff in some situations, but it's a lot more complicated than it seems.

Yeah, this sums up my opinion on this topic.

Also, having spent a couple of years writing and debugging big and small greenlet-heavy code bases I wouldn't want to touch them ever again. Your mileage may vary, Mike.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:55:22 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Jul 2020 19:55:22 +0000
Subject: [issue41188] Prepare CPython for opaque PyObject structure.
In-Reply-To: <1593625382.35.0.32807501167.issue41188@roundup.psfhosted.org>
Message-ID: <1594151722.14.0.723524229279.issue41188@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41188>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:58:58 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 19:58:58 +0000
Subject: [issue23802] patch: __deepcopy__ memo dict argument usage
In-Reply-To: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>
Message-ID: <1594151938.86.0.768922041699.issue23802@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

The Pr should sort this. I will merge it tommorrow if there is no objection.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23802>
_______________________________________

From report at bugs.python.org  Tue Jul  7 16:09:13 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 20:09:13 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1594152553.41.0.107416870922.issue39417@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Looks like this should be closed as the submitted PR was merged. Just following up for consesus.

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Tue Jul  7 16:12:53 2020
From: report at bugs.python.org (mike bayer)
Date: Tue, 07 Jul 2020 20:12:53 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594152773.13.0.87394393865.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

> With greenlets OTOH, it becomes possible for another task to observe someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally invoked an await_(). Any operation can potentially invoke a context switch. So debugging greenlets code is roughly as hard as debugging full-on multithreaded code, and much harder than debugging async/await code.

I would invite you to look more closely at my approach.   The situation you describe above applies to a library like gevent, where IO means a context switch that can go anywhere.  My small recipe never breaks out of the asyncio event loop, and it only context switches within the scope of a single coroutine, not to any arbitrary coroutine.   So I don't think the above issue applies.

Additionally, we are here talking about *libraries* that are independently developed and tested distinct from end-user code.    If there's a bug in SQLAlchemy, the end user isn't the person debugging that.   arguments over "is async or sync easier to debug" are IMO pretty subjective and at this point they are not relevant to what sync-based libraries should be doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 16:26:12 2020
From: report at bugs.python.org (mike bayer)
Date: Tue, 07 Jul 2020 20:26:12 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594153572.12.0.00537732106629.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

> With greenlets OTOH, it becomes possible for another task to observe someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally invoked an await_().

let me try this one more time.    Basically if someone wrote this:

async def do_thing():
   someobj.a =1
   await do_io_setattr(someobj, "b", 2)

then in the async approach, you can again say, assuming "someobj" is global, that another task can observe "someobj.a == 1" without "someobj.b == 2".    I suppose you are making the argument that because there's an "await" keyword there, now everything is OK because the reader of the code knows there's a context switch.

Whether or not one buys that, the point of my approach is that SQLAlchemy itself *will* publish async methods.  End user code *will not* ever context switch to another task without them explicitly calling using an await.  That SQLAlchemy internally is not using this coding style, whether or not that leads to new kinds of bugs, there are new kinds of bugs no matter what kind of code a library uses, I don't think this hurts the user community.  The community is hurting *A LOT* right now because asyncio is intentionally non-compatible with the traditional blocking approach that is not only still prevalent it's one that a lot of us think is *easier* to work with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 16:31:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jul 2020 20:31:48 +0000
Subject: [issue17238] IDLE: Add import statement completion
In-Reply-To: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za>
Message-ID: <1594153908.61.0.608485368974.issue17238@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

+1 for import completion.  Above, I misspelled 'rlcompleter' as 'rlcomplete'.  When I just tried to import it as part of responding to #41230, the wrong name did not work.  I wish I could have stopped with 'import rl'<tab>.  To add a note to #37765, I tried 'import keywords'.  Nope, no 's'.  'import ke'<tab> would have been nice.  I suspect that some beginners have as much trouble with names they have no recently used.

im<tab> would work if keywords were added to the tab completion list. #37765.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17238>
_______________________________________

From report at bugs.python.org  Tue Jul  7 16:43:04 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 07 Jul 2020 20:43:04 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594154584.38.0.871360065094.issue22239@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The community is hurting *A LOT* right now because asyncio is intentionally non-compatible with the traditional blocking approach that is not only still prevalent it's one that a lot of us think is *easier* to work with.

Mike, I'm super happy with having you here and I encourage you to propose feature requests etc. That said, please don't use arguments like this here. Everyone has their own point of view and I, for example, haven't seen the "A LOT of community hurt" you're describing. I'm not implying that what you're saying is wrong, or that asyncio is perfect; the point is that it's just very subjective. The bug tracker is not the medium for these kind of remarks.

> That SQLAlchemy internally is not using this coding style, whether or not that leads to new kinds of bugs, there are new kinds of bugs no matter what kind of code a library uses, I don't think this hurts the user community.

You're free to use whatever approach you want in SQLAlchemy. We're here to share our advice and perspective (if we have any) and/or to discuss concrete proposals for API improvements or changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:11:53 2020
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jul 2020 21:11:53 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594156313.31.0.0217921109154.issue41206@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm short of time, if someone could approve Mark's PR and merge it it would be great. There wasn't supposed to be any behavior change other than the one documented in #40597.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:12:52 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Tue, 07 Jul 2020 21:12:52 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1594156372.31.0.00262969151543.issue1635741@roundup.psfhosted.org>


Change by mohamed koubaa <koubaa.m at gmail.com>:


----------
pull_requests: +20522
pull_request: https://github.com/python/cpython/pull/21378

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:15:39 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 07 Jul 2020 21:15:39 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594156539.35.0.439840526522.issue22239@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> Whether or not one buys that, the point of my approach is that SQLAlchemy itself *will* publish async methods.  End user code *will not* ever context switch to another task without them explicitly calling using an await.

Oh, I thought the primary problem for SQLAlchemy supporting async is that the ORM needs to do IO from inside __getattr__ methods. So I assumed that the reason you were so excited about greenlets was that it would let you use await_() from inside those __getattr__ calls, which would involve exposing your use of greenlets as part of your public API.

If you're just talking about using greenlets internally and then writing both sync and async shims to be your public API, then obviously that reduces the risks. Maybe greenlets will cause you problems, maybe not, but either way you know what you're getting into and the decision only affects you :-). But, if that's all you're using them for, then I'm not sure that they have a significant advantage over the edgedb-style synchronous wrapper or the unasync-style automatically generated sync code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:21:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jul 2020 21:21:13 +0000
Subject: [issue37765] IDLE: Include longer keywords in __main__ autocomplete
 list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594156873.73.0.579103756135.issue37765@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: IDLE: Include 'long' keywords in __main__ autocomplete list -> IDLE: Include longer keywords in __main__ autocomplete list

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:20:43 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jul 2020 21:20:43 +0000
Subject: [issue37765] IDLE: Include 'long' keywords in __main__ autocomplete
 list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594156843.96.0.818441387662.issue37765@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Cheryl said "This looks good" on the PR." while noting that True should not be added as  After trying out REPL completions in macOS Terminal, I *really* want to be able to type 'im'<tab> and have 'import' appear.  (When there is just one match, it is filled in without displaying a list of one item.)  I increasingly suffer from 'dystypia' (which I coined as the reverse of 'dyslexia'), and 'import' is one of my worst words.  And I have to type it daily.  On #17238, Ramchandra Apte also requested completion of 'import'.

Sorting keywords by length, we get:
>>> sorted(keyword.kwlist, key=lambda s: len(s))
['as', 'if', 'in', 'is', 'or', 'and', 'def', 'del', 'for', 'not', 'try', 'None', 'True', 'elif', 'else', 'from', 'pass', 'with', 'False', 'async', 'await', 'break', 'class', 'raise', 'while', 'yield', 'assert', 'except', 'global', 'import', 'lambda', 'return', 'finally', 'continue', 'nonlocal', '__peg_parser__']

I agree that adding 2 and 3 letter keywords is not useful. Among 4 letter keywords, None and True are already present from builtins.  'elif' and 'else' would need at least 3 and 4 keystrokes to complete ('e', <Tab>, Down for 'else', <Enter>).  'from' would need at least 4 because of 'filter' and 'frozenset'.  'pass' would need 3 because of 'pow'.  'with' would require at least 5 if 'while' were added.  So skip length 4 keywords also.

So I am changing the proposal to adding the 17 keywords (other than False, already present) of length 5 or more.  These include 'async' and 'await', requested by Karthikeyan in the opening post above.

----------
title: IDLE: Include keywords in __main__ autocomplete list -> IDLE: Include 'long' keywords in __main__ autocomplete list
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:42:21 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 07 Jul 2020 21:42:21 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a ValueError
 instead of an ImportError
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1594158141.63.0.705495544671.issue16396@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:43:10 2020
From: report at bugs.python.org (Tal Einat)
Date: Tue, 07 Jul 2020 21:43:10 +0000
Subject: [issue37765] IDLE: Include longer keywords in __main__ autocomplete
 list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594158190.67.0.246255781814.issue37765@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Also, note that the keywords would only be included in the suggested completions when not in a string and when not completing an attribute. So, for example, such a change could not possibly affect the completion of dunder method names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:40:02 2020
From: report at bugs.python.org (Tal Einat)
Date: Tue, 07 Jul 2020 21:40:02 +0000
Subject: [issue37765] IDLE: Include longer keywords in __main__ autocomplete
 list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594158002.91.0.608050514542.issue37765@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Auto-completion is not just about saving keystrokes. For example, I assume that many Python beginners just read through the completion list to see what the options are. This inconsistency would be hard to grok.

I think that including only some of the keywords in the completions list could potentially be very confusing. We'd have "class" but not "def", "finally" but not "else", "while" but not "for".

If the standard REPL completes keywords (at least on some platforms) that's a good enough argument to include them in IDLE, in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:48:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jul 2020 21:48:20 +0000
Subject: [issue41230] IDLE intellisense
In-Reply-To: <1594124257.05.0.294353928422.issue41230@roundup.psfhosted.org>
Message-ID: <1594158500.64.0.226689763072.issue41230@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE already has autocomplete of names, attributes, and string paths.  This is documented in the Completion subsection of the Editing and Navigation section of the doc, easily accessible on the Help menu.  Please read the doc before suggesting enhancements.

Issue 27609 summarizes approximately 10 existing bpo issues for improving completions.  Please check the list there before suggesting a specific change.

I believe that 'Intellisense' is a Microsoft's trademark for a Visual Studio feature.  It should not be used generically.  Since I only ever used VS, in the past, to compile python.exe, I never knew what Intellisense did, just that it made me wait when I opened VS.  (/PCBuild in the CPython repository now has build.bat to directly invoke the compiler without this delay.)

I am guessing from your wording that at least part of the Intellisense delay is to recompile the database needed for completions.  As a C++ program, VS cannot import python the current text of python modules the way that a python-coded IDE can.  It might be nice to add something to the stdlib that could be used by any python editor or shell, but I will not pursue that until existing issues are finished.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE completions: format, factor, and fix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41230>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:00:22 2020
From: report at bugs.python.org (Thor Whalen)
Date: Tue, 07 Jul 2020 22:00:22 +0000
Subject: [issue41232] Python `functools.wraps` doesn't deal with defaults
 correctly
Message-ID: <1594159222.49.0.432639092165.issue41232@roundup.psfhosted.org>


New submission from Thor Whalen <thorwhalen1 at gmail.com>:

# PROBLEM

When using `functools.wraps`, the signature claims one set of defaults, but the (wrapped) function uses the original (wrappee) defaults.

Why might that be the desirable default?

# PROPOSED SOLUTION
Adding '__defaults__',  '__kwdefaults__' to `WRAPPER_ASSIGNMENTS` so that actual defaults can be consistent with signature defaults.

# Code Demo

```python
from functools import wraps
from inspect import signature

def g(a: float, b=10):
    return a * b

def f(a: int, b=1):
    return a * b

assert f(3) == 3

f = wraps(g)(f)

assert str(signature(f)) == '(a: float, b=10)'  # signature says that b defaults to 10
assert f.__defaults__ == (1,)  # ... but it's a lie!
assert f(3) == 3 != g(3) == 30  # ... and one that can lead to problems!
```

Why is this so? Because `functools.wraps` updates the `__signature__` (including annotations and defaults), `__annotations__`, but not `__defaults__`, which python apparently looks to in order to assign defaults.

One solution is to politely ask wraps to include these defaults.

```python
from functools import wraps, WRAPPER_ASSIGNMENTS, partial

my_wraps = partial(wraps, assigned=(list(WRAPPER_ASSIGNMENTS) + ['__defaults__', '__kwdefaults__']))

def g(a: float, b=10):
    return a * b

def f(a: int, b=1):
    return a * b

assert f(3) == 3

f = my_wraps(g)(f)

assert f(3) == 30 == g(3)
assert f.__defaults__ == (10,)  # ... because now got g defaults!
```

Wouldn't it be better to get this out of the box?

When would I want the defaults that are actually used be different than those mentioned in the signature?

<!--
Thanks for your contribution!
Please read this comment in its entirety. It's quite important.

# Pull Request title

It should be in the following format:

```
bpo-NNNN: Summary of the changes made
```

Where: bpo-NNNN refers to the issue number in the https://bugs.python.org.

Most PRs will require an issue number. Trivial changes, like fixing a typo, do not need an issue.

# Backport Pull Request title

If this is a backport PR (PR made against branches other than `master`),
please ensure that the PR title is in the following format:

```
[X.Y] <title from the original PR> (GH-NNNN)
```

Where: [X.Y] is the branch name, e.g. [3.6].

GH-NNNN refers to the PR number from `master`.

-->

----------
messages: 373254
nosy: Thor Whalen2
priority: normal
severity: normal
status: open
title: Python `functools.wraps` doesn't deal with defaults correctly
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41232>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:10:41 2020
From: report at bugs.python.org (Thor Whalen)
Date: Tue, 07 Jul 2020 22:10:41 +0000
Subject: [issue41232] Python `functools.wraps` doesn't deal with defaults
 correctly
In-Reply-To: <1594159222.49.0.432639092165.issue41232@roundup.psfhosted.org>
Message-ID: <1594159841.78.0.87857441911.issue41232@roundup.psfhosted.org>


Thor Whalen <thorwhalen1 at gmail.com> added the comment:

Posted to stackoverflow to gather opinions about the issue: https://stackoverflow.com/questions/62782230/python-functools-wraps-doesnt-deal-with-defaults-correctly

Also made GitHub PR: https://github.com/python/cpython/pull/21379

----------
keywords: +patch
message_count: 1.0 -> 2.0
pull_requests: +20523
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21379

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41232>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:18:12 2020
From: report at bugs.python.org (Thor Whalen)
Date: Tue, 07 Jul 2020 22:18:12 +0000
Subject: [issue41232] Python `functools.wraps` doesn't deal with defaults
 correctly
In-Reply-To: <1594159222.49.0.432639092165.issue41232@roundup.psfhosted.org>
Message-ID: <1594160292.87.0.489171460639.issue41232@roundup.psfhosted.org>


Thor Whalen <thorwhalen1 at gmail.com> added the comment:

Further, note that even with the additional '__defaults__', and '__kwdefaults__', `functools.wraps` breaks when keyword only arguments involved:

```
from functools import wraps, WRAPPER_ASSIGNMENTS, partial

# First, I need to add `__defaults__` and `__kwdefaults__` to wraps, because they don't come for free...
my_wraps = partial(wraps, assigned=(list(WRAPPER_ASSIGNMENTS) + ['__defaults__', '__kwdefaults__']))

def g(a: float, b=10):
    return a * b

def f(a: int,  *, b=1):
    return a * b

# all is well (for now)...
assert f(3) == 3
assert g(3) == 30
```

This:
```
my_wraps(g)(f)(3)
```
raises TypeError (missing required positional argument 'b'), expected

Note that `wraps(g)(f)(3)` doesn't throw a TypeError, but the output is not consistent with the signature (inspect.signature(wraps(g)(f)) is (a: float, b=10), so 3 should be multiplied by 10). This is because __defaults__ wasn't updated. See for example, that third-party from boltons.funcutils import wraps works as expected. And so do (the very popular) wrapt and decorator packages. Boltons works for wraps(f)(g), but not wraps(g)(f) in my example. 

See: https://stackoverflow.com/questions/62782709/pythons-functools-wraps-breaks-when-keyword-only-arguments-involved

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41232>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:20:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jul 2020 22:20:44 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594160444.6.0.224540875512.issue29778@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8f42748ded5e978fe8a924115179d45a74a6363b by Victor Stinner in branch 'master':
bpo-29778: test_embed tests the path configuration (GH-21306)
https://github.com/python/cpython/commit/8f42748ded5e978fe8a924115179d45a74a6363b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:24:01 2020
From: report at bugs.python.org (David Caro)
Date: Tue, 07 Jul 2020 22:24:01 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
In-Reply-To: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>
Message-ID: <1594160641.04.0.680980988441.issue41231@roundup.psfhosted.org>


David Caro <david at dcaro.es> added the comment:

Hi Terry,

That would not work in this case, as I'd want to override all annotations with the wrapper function ones if there's any, instead of merging them.

The specific use case, is a type checker (part of TestSlide testing framework), to verify that if there's any type annotations, the parameters mocked and passed to it are the expected types.

For example, the contextmanager decorator returns an actual ContextManager, wrapping whatever the wrapped function returned, so if the wrapped function annotations prevail, then there's no way if verifying that the returned type is correct.

Thanks for the ChainMap pointer though, I'll use it for sure somewhere else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41231>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:29:55 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jul 2020 22:29:55 +0000
Subject: [issue27609] IDLE completions: format, factor, and fix
In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za>
Message-ID: <1594160995.85.0.891940294598.issue27609@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

fetch_completions code could stand some refactoring.  The test should be split at least between attrs and files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27609>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:39:26 2020
From: report at bugs.python.org (yyyyyyyan)
Date: Tue, 07 Jul 2020 22:39:26 +0000
Subject: [issue41233] Missing links to errnos on Built-in Exceptions page
Message-ID: <1594161566.11.0.329793156149.issue41233@roundup.psfhosted.org>


New submission from yyyyyyyan <yanorestes at hotmail.com>:

On the [Built-in Exceptions](https://docs.python.org/dev/library/exceptions.html) page, the exception [InterruptedError](https://docs.python.org/dev/library/exceptions.html#InterruptedError) correlates the error with the errno [EINTR](https://docs.python.org/dev/library/errno.html#errno.EINTR), linking the name `EINTR` with the errno page. This is great, since reading "*corresponds to errno EINTR*" is pointless if you don't know what `EINTR` means. The problem is `InterruptedError` is the only exception that put a link on the errno. All others only have the "correspondes to errno `ERRNO`", without any links, which makes it harder to understand.

The same thing happens on the [errno](https://docs.python.org/dev/library/errno.html). On the section about [errno.EINTR](https://docs.python.org/dev/library/errno.html#errno.EINTR) we have a "see also" box saying "This error is mapped to the exception InterruptedError", with a link to the InterruptedError section on the exceptions page. However, for some reason the "see also" box is only on this specific errno section.

The links should be added on both pages so the great pattern defined by `InterruptedError` and `errno.EINTR` is mantained.

----------
assignee: docs at python
components: Documentation
messages: 373260
nosy: docs at python, eric.araujo, ezio.melotti, mdk, willingc, yyyyyyyan
priority: normal
severity: normal
status: open
title: Missing links to errnos on Built-in Exceptions page
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/issue41233>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:47:12 2020
From: report at bugs.python.org (jack1142)
Date: Tue, 07 Jul 2020 22:47:12 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1594162032.84.0.839176135112.issue37373@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:47:22 2020
From: report at bugs.python.org (yyyyyyyan)
Date: Tue, 07 Jul 2020 22:47:22 +0000
Subject: [issue41233] Missing links to errnos on Built-in Exceptions page
In-Reply-To: <1594161566.11.0.329793156149.issue41233@roundup.psfhosted.org>
Message-ID: <1594162042.99.0.474336246612.issue41233@roundup.psfhosted.org>


Change by yyyyyyyan <yanorestes at hotmail.com>:


----------
keywords: +patch
pull_requests: +20524
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21380

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41233>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:51:30 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 22:51:30 +0000
Subject: [issue41234] Remove symbol.sym_name
Message-ID: <1594162290.58.0.321462635772.issue41234@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

symbol.sym_name was already removed yet still documented in library/symbol.rst.

I suggest completely removing the docs too since the module is non-existing.

----------
components: Library (Lib)
messages: 373261
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Remove symbol.sym_name
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41234>
_______________________________________

From report at bugs.python.org  Tue Jul  7 18:56:44 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 22:56:44 +0000
Subject: [issue41234] Remove symbol.sym_name
In-Reply-To: <1594162290.58.0.321462635772.issue41234@roundup.psfhosted.org>
Message-ID: <1594162604.92.0.00449469339417.issue41234@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +20526
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21381

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41234>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:09:59 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 23:09:59 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1594163399.97.0.829832053199.issue41224@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset a95ac779e6bca0d87819969e361627182b83292c by Joannah Nanjekye in branch 'master':
bpo-41224: Document is_annotated() in symtable module and update doc strings (GH-21369)
https://github.com/python/cpython/commit/a95ac779e6bca0d87819969e361627182b83292c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:10:29 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 07 Jul 2020 23:10:29 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1594163429.66.0.443740829892.issue41224@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:24:46 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jul 2020 23:24:46 +0000
Subject: [issue41173] Windows ARM buildbots cannot upload results
In-Reply-To: <1593532689.42.0.224097599218.issue41173@roundup.psfhosted.org>
Message-ID: <1594164286.9.0.228156667254.issue41173@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 10772ec1505a4583d662c051e577eb2d4fb6e755 by Steve Dower in branch 'master':
bpo-41173: Copy test results file from ARM worker before uploading (GH-21305)
https://github.com/python/cpython/commit/10772ec1505a4583d662c051e577eb2d4fb6e755


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41173>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:25:28 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 23:25:28 +0000
Subject: [issue41173] Windows ARM buildbots cannot upload results
In-Reply-To: <1593532689.42.0.224097599218.issue41173@roundup.psfhosted.org>
Message-ID: <1594164328.65.0.155300346506.issue41173@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +20527
pull_request: https://github.com/python/cpython/pull/21382

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41173>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:26:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jul 2020 23:26:20 +0000
Subject: [issue41173] Windows ARM buildbots cannot upload results
In-Reply-To: <1593532689.42.0.224097599218.issue41173@roundup.psfhosted.org>
Message-ID: <1594164380.16.0.565751713707.issue41173@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41173>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:32:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jul 2020 23:32:12 +0000
Subject: [issue27609] IDLE completions: format, factor, and fix
In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za>
Message-ID: <1594164732.42.0.406764855688.issue27609@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Normally, tab completion works for attributes (after '.' and a possible prefix) and files (after os.sep and a possible prefix).  Unique matches to prefixes are immediately selected, as for undotted module names.  After changing the completion wait time and before restarting, this is disabled and tab adds spaces instead.  This need a new issue and fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27609>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:39:48 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 23:39:48 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1594165188.95.0.301151673515.issue39417@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +20528
pull_request: https://github.com/python/cpython/pull/21383

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:41:23 2020
From: report at bugs.python.org (Mariatta)
Date: Tue, 07 Jul 2020 23:41:23 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1594165283.94.0.999107086047.issue39417@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Just needed a backport to 3.8 (which is in flight) so this is good to be closed.
Thanks.

----------
nosy: +Mariatta
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:45:23 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 23:45:23 +0000
Subject: [issue41173] Windows ARM buildbots cannot upload results
In-Reply-To: <1593532689.42.0.224097599218.issue41173@roundup.psfhosted.org>
Message-ID: <1594165523.85.0.723068763328.issue41173@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 366cfc65f26b159e44ee30917ab35afe59f8339f by Miss Islington (bot) in branch '3.9':
bpo-41173: Copy test results file from ARM worker before uploading (GH-21305)
https://github.com/python/cpython/commit/366cfc65f26b159e44ee30917ab35afe59f8339f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41173>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:47:12 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jul 2020 23:47:12 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1594165632.4.0.495893885754.issue39417@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 730bce3a80819e0b7fa6bfa1e1afcd4c837b62c1 by Miss Islington (bot) in branch '3.8':
bpo-39417: Fix broken link to guide to building venvs (GH-18432)
https://github.com/python/cpython/commit/730bce3a80819e0b7fa6bfa1e1afcd4c837b62c1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Tue Jul  7 20:46:28 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 08 Jul 2020 00:46:28 +0000
Subject: [issue41225] Add a test for get_id() in the symtable module
In-Reply-To: <1594083475.77.0.464939543595.issue41225@roundup.psfhosted.org>
Message-ID: <1594169188.92.0.959708657866.issue41225@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
components: +Tests
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41225>
_______________________________________

From report at bugs.python.org  Tue Jul  7 21:41:55 2020
From: report at bugs.python.org (Maxwell Ballenger)
Date: Wed, 08 Jul 2020 01:41:55 +0000
Subject: [issue21041] pathlib.PurePath.parents rejects negative indexes
In-Reply-To: <1395613011.22.0.29152070109.issue21041@psf.upfronthosting.co.za>
Message-ID: <1594172515.46.0.545809771467.issue21041@roundup.psfhosted.org>


Maxwell Ballenger <ballengerm at gmail.com> added the comment:

Use case: I want to see if a Path is a descendent of /tmp.

if filepath.parents[-2] == Path('tmp'):

turns into

if filepath.parents[len(filepath.parents)-2] == Path('tmp'):

----------
nosy: +maxballenger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21041>
_______________________________________

From report at bugs.python.org  Tue Jul  7 22:07:15 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 02:07:15 +0000
Subject: [issue41227] minor typo in asyncio transport protocol
In-Reply-To: <1594092816.12.0.525496493671.issue41227@roundup.psfhosted.org>
Message-ID: <1594174035.3.0.902527028847.issue41227@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
nosy: +ys19991
nosy_count: 4.0 -> 5.0
pull_requests: +20529
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21384

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41227>
_______________________________________

From report at bugs.python.org  Tue Jul  7 23:44:22 2020
From: report at bugs.python.org (mike bayer)
Date: Wed, 08 Jul 2020 03:44:22 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594179862.3.0.875058244526.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

> Oh, I thought the primary problem for SQLAlchemy supporting async is that the ORM needs to do IO from inside __getattr__ methods. So I assumed that the reason you were so excited about greenlets was that it would let you use await_() from inside those __getattr__ calls, which would involve exposing your use of greenlets as part of your public API.


The primary problem is people want to execute() a SQL statement using await, and then they want to use a non-blocking database driver (basically asyncpg, I'm not sure there are any others, maybe there's one for MySQL also) on the back.    Tools like aiopg have provided partial SQLAlchemy-like front-ends to accomplish this but they can't do ORM support, not because the ORM has lazy loading, but just to do explicit operations like query.all() or session.flush() that can sometimes require a lot of front-to-back database operations to complete which would be very involved to rewrite all that code using async/await.

Then there's the secondary problem of ORMs doing lazy loading, which is what you refer towards as "IO inside __getattr__ methods".   SQLAlchemy is not actually as dependent on lazy loading as other ORMs as we support a wide range of ways to "eagerly" load data up front.  With the SQLAlchemy 2.0-style ORM API that has a clear spot for "await" to occur, they can call "await session.execute(select(SomeObject))" and get a whole traversible graph of things loaded up front.    We even have a loader called "raiseload" that is specifically anti-lazy loading, it's a loader that raises an error if you try to access something that wasn't explicitly loaded already.  So for a lot of cases we are already there.

But then, towards your example of "something.b = x", or more commonly in ORMS a get operation like "something.b" emitting SQL, the extension I'm building will very likely include some kind of feature that they can do this with an explicit call.  At the moment with the preliminary code that's in there, this might look like:

   await greenlet_spawn(getattr, something, "b")

not very pretty at the moment but that general idea.   

But the thing is, greenlet_spawn() can naturally apply to anything.  So it remains to be seen both how I would want to present this notion, as well as if people are going to be interested in it or not, but as a totally extra thing beyond the "await session.execute()" API that is the main thing, someone could do something like this:

   await greenlet_spawn(my_business_orm_method)

and then in "my_business_orm_method()", all the blocking style ORM things that async advocates warn against could be happening in there.     I'm certainly not going to tell people they have to be doing that, but I dont think I should discourage it either, because if the above business method is written "reasonably" (see next paragraph), there really is no problem introduced by implicit IO.

By "written reasonably" I'm referring to the fact that in this whole situation, 90% of everything people are doing here are in the context of HTTP services.   The problem of, "something.a now creates state that other tasks might see" is not a real "problem" that is solved by using IO-only explicit context switching.  This is because in a CRUD-style application, "something" is not going to be a process-local yet thread-global object that had to be created specifically for the application (there's things like the database connection pool and some registries that the ORM uses, but those problems are taken care of and aren't specific to one particular application).     There is certainly going to be global mutable state with the CRUD/HTTP application which is the database itself.  Event based programming doesn't save you from concurrency issues here because any number of processes maybe accessing the database at the same time.  There are well-established concurrency patterns one uses with relational databases, which include first and foremost transaction isolation, but also things like compare-and-swap, "select for update", ensuring MVCC is turned on (SQL Server), table locks, etc.  These techniques are independent of the concurrency pattern used within the application, and they are arguably better suited to blocking-style code in any case because on the database side we must emit our commands within a transaction serially in any case.   The major convenient point of "async" that we can fire off a bunch of web service requests in parallel does not apply to the CRUD-style business methods within our web service request because we can only do things in our ACID transaction one at a time.

The problem of "something.a" emitting IO needs to be made sane against other processes also viewing or altering "something.a", assuming "something" is a database-bound object like a row in a table, using traditional database concurrency constructs such as choosing an appropriate isolation mode, using atomically-composed SQL statements, things like that.   The problem of two greenlets or coroutines seeing "something" before it's been fully altered would happen across two processes in any case, but if "something" is a database row, that second greenlet would not see "something.a / something.b" in mid-flight because the isolation level is going to be at least "read committed".

In the realm of Python HTTP/CRUD applications, async is actually very popular however it is in the form of gevent and sometimes eventlet monkeypatching, often because people are using async web servers like gunicorn.    I don't see much explicit async at all because as mentioned before, there are very few async database drivers and there are also very few async database abstraction layers.   I've sort of made a side business at work out of helping people with the problems of gevent-enabled HTTP services.  There are two problems that I see: the main one is that they configure their workers for 1000 greenlets, they set their database connection pool to only allow 20 database connections, and then their processes get totally hung as all the requests pile up in one process that is advertising that it still has 980 more requests it can service.  The other one is that their application is completely CPU bound, and sometimes so badly that we see database timeouts because their greenlets can't respond to a database ping or authentication challenge within 30 seconds.   I have never seen any issues related to the fact that IO is implicit or that lazy loading confused someone.    Maybe this is a thing if they had some kind of microservice-parallel HTTP request spawning monster of some kind but we don't have that kind of thing in CRUD applications.

The two aforementioned problems with too many greenlets or coroutines vs. what their application can actually handle would occur just as much with an explicit async driver, and that's fine, I know how to debug these cases.  But in any case, people are already writing huge CRUD apps that run under gevent.   To my secondary idea that someone can run their app using asyncio and then on an *as needed* basis put some more CRUD-like methods into greenlets with blocking style code, this is an *improvement* over the current state of affairs where everything everywhere is implicit IO.  Not only that, but they can do this already common programming style and interact with a database driver that is *designed for async*.   Right now everyone uses pymysql because it is pure Python and therefore can have all the socket / IO related code monkeypatched by gevent.  It's bad.  Whether or not one thinks writing HTTP services using greenlets is a good idea or not, it is definitely better to do it using a database driver that is designed for async talking to the database without doing any monkeypatching.  My approach makes this possible where it has previously not been possible at all, so I think this represents a big improvement to an already popular programming pattern while at the same time introduces the notion of a single application using both explicit and implicit approaches simultaneously.

I think the notion that someone who really wants to use async/await in order to carefully schedule how they communicate with other web services and resources which often need to be loaded in parallel, but then for their transactional CRUD code which is necessarily serial in any case they can write those parts in blocking style, is a good thing.    This style of code is already prevalent and here we'd be giving an application the ability to use both styles simultaneously.   I had always hoped that Python's move towards asyncio would allow this programming paradigm to flourish as it seems inherently useful.  


> If you're just talking about using greenlets internally and then writing both sync and async shims to be your public API, then obviously that reduces the risks. Maybe greenlets will cause you problems, maybe not, but either way you know what you're getting into and the decision only affects you :-). But, if that's all you're using them for, then I'm not sure that they have a significant advantage over the edgedb-style synchronous wrapper or the unasync-style automatically generated sync code.> 

w.r.t the issue of writing everything as async and then using the coroutine primitives to convert to "sync" as means of maintaining both facades, I don't think that covers the fact that most DBAPI drivers are sync only (and not monkeypatchable either, but I think we all agree here that monkeypatching is terrible in any case), and to suit the much more common use case of sync front end -> agnostic middle -> sync driver, to go from an async event loop to a blocking IO database driver you need to use a thread executor of some kind.    The other way around, that the library code is written in "sync" and you can attach "async" to both ends of it using greenlets in the middle, much more lightweight of a transition in that direction, vs. the transition of async internals out to a sync only driver.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Tue Jul  7 23:55:25 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 08 Jul 2020 03:55:25 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
Message-ID: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

If the SSL_CTX_set_tmp_dh() call fails, SSLContext.load_dh_params() returns
None with a live exception.  It should return NULL in this case.

----------
assignee: christian.heimes
components: Extension Modules, SSL
messages: 373271
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: Incorrect error handling in SSLContext.load_dh_params()
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Tue Jul  7 23:57:34 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 08 Jul 2020 03:57:34 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594180654.02.0.290428410794.issue41235@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +20530
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21385

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:00:14 2020
From: report at bugs.python.org (mike bayer)
Date: Wed, 08 Jul 2020 04:00:14 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594180814.45.0.697530859997.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

slight correction: it is of course possible to use gevent with a database driver without monkeypatching, as I wrote my own gevent benchmarks using psycogreen.  I think what I'm getting at is that it's a good thing if async DBAPIs could target asyncio explicitly rather than having to write different gevent/eventlet specific things, and that tools like SQLAlchemy can allow for greenlet style coding against those DBAPIs without one having to install/run the whole gevent event loop.   Basically I like the greenlet style of coding but I would be excited to skip the gevent part, never do any monkeypatching again, and also have other parts of the app doing asyncio work with other kinds of services.     this is about interoperability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:21:12 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Wed, 08 Jul 2020 04:21:12 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1594182072.89.0.119348082333.issue41205@roundup.psfhosted.org>


Change by Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com>:


----------
keywords: +patch
nosy: +thatiparthy
nosy_count: 7.0 -> 8.0
pull_requests: +20532
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21386

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:22:01 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 08 Jul 2020 04:22:01 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594182121.56.0.121006388401.issue41235@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset aebc0495572c5bb85d2bd97d27cf93ab038b5a6a by Zackery Spytz in branch 'master':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() (GH-21385)
https://github.com/python/cpython/commit/aebc0495572c5bb85d2bd97d27cf93ab038b5a6a


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:22:22 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 04:22:22 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594182142.66.0.116193127384.issue41235@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20533
pull_request: https://github.com/python/cpython/pull/21387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:22:39 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 04:22:39 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594182159.31.0.945126402072.issue41235@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20535
pull_request: https://github.com/python/cpython/pull/21389

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:22:31 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 04:22:31 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594182151.26.0.887171102462.issue41235@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20534
pull_request: https://github.com/python/cpython/pull/21388

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:37:57 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 04:37:57 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594183077.25.0.0668826066339.issue41235@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c8b599ff0a4e4782e97e353a20146d3570845dbc by Miss Islington (bot) in branch '3.8':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() (GH-21385)
https://github.com/python/cpython/commit/c8b599ff0a4e4782e97e353a20146d3570845dbc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:40:21 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 04:40:21 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594183221.65.0.620591198179.issue41235@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1d1c5743400bdf384ec83eb6ba5b39a355d121e3 by Miss Islington (bot) in branch '3.9':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() (GH-21385)
https://github.com/python/cpython/commit/1d1c5743400bdf384ec83eb6ba5b39a355d121e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:55:43 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 08 Jul 2020 04:55:43 +0000
Subject: [issue41235] Incorrect error handling in SSLContext.load_dh_params()
In-Reply-To: <1594180525.01.0.333549128836.issue41235@roundup.psfhosted.org>
Message-ID: <1594184143.77.0.23450910519.issue41235@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset c8c818b0d73680516d5841597b705a1feeb42113 by Miss Islington (bot) in branch '3.7':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() (GH-21389)
https://github.com/python/cpython/commit/c8c818b0d73680516d5841597b705a1feeb42113


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41235>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:05:16 2020
From: report at bugs.python.org (Baozhen Chen)
Date: Wed, 08 Jul 2020 06:05:16 +0000
Subject: [issue41236] "about" button in MacOS caused an error
Message-ID: <1594188316.81.0.4505690312.issue41236@roundup.psfhosted.org>


New submission from Baozhen Chen <baozhen.chen at shopee.com>:

when clicking the MacOS menubar-File-About Python, it appears

>>> can't invoke "tk_messageBox" command: application has been destroyed
    while executing
"tk_messageBox -icon info -type ok -title [mc "About Widget Demo"]  -message [mc "Tk widget demonstration application"] -detail  "[mc "Copyright \u00a9..."
    (procedure "tkAboutDialog" line 2)
    invoked from within
"tkAboutDialog"

----------
components: macOS
messages: 373278
nosy: Baozhen Chen, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: "about" button in MacOS caused an error
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41236>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:09:25 2020
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 08 Jul 2020 06:09:25 +0000
Subject: [issue41237] Access violation in python39.dll!meth_dealloc on exit
Message-ID: <1594188565.24.0.738467793313.issue41237@roundup.psfhosted.org>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

When testing extension packages on Python 3.9.0b4 for Windows, I often get access violations in `python39.dll!meth_dealloc` during interpreter exit. The crash only happens when heap verification is turned on (`"C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\gflags.exe" /p /enable python.exe`; https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags). The debug build does not crash.

Could be related to "PEP 573: Module State Access from C Extension Methods", https://bugs.python.org/issue38787

To reproduce the crash with with numpy-1.19.0 (built from source):
```
Python 3.9.0b4 (tags/v3.9.0b4:69dec9c, Jul  2 2020, 21:46:36) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy;numpy.test()
NumPy version 1.19.0
<snip>
10364 passed, 438 skipped, 108 deselected, 17 xfailed, 1 xpassed in 243.52s (0:04:03)
True
>>> exit()
Windows fatal exception: access violation

Current thread 0x00002688 (most recent call first):
<no Python frame>
```

The crash is at <https://github.com/python/cpython/blob/1d1c5743400bdf384ec83eb6ba5b39a355d121e3/Objects/methodobject.c#L169>:
```
static void
meth_dealloc(PyCFunctionObject *m)
{
    _PyObject_GC_UNTRACK(m);
    if (m->m_weakreflist != NULL) {
        PyObject_ClearWeakRefs((PyObject*) m);
    }
    Py_XDECREF(m->m_self);
    Py_XDECREF(m->m_module);
    Py_XDECREF(PyCFunction_GET_CLASS(m));  /* <-- crash */
    PyObject_GC_Del(m);
}
```

Call Stack:
```
>	python39.dll!meth_dealloc(PyCFunctionObject * m) Line 169	C
 	[Inline Frame] python39.dll!_Py_Dealloc(_object *) Line 2209	C
 	[Inline Frame] python39.dll!_Py_DECREF(_object *) Line 430	C
 	[Inline Frame] python39.dll!_Py_XDECREF(_object * op) Line 497	C
 	[Inline Frame] python39.dll!free_keys_object(_dictkeysobject *) Line 598	C
 	[Inline Frame] python39.dll!dictkeys_decref(_dictkeysobject *) Line 333	C
 	python39.dll!dict_dealloc(PyDictObject * mp) Line 2026	C
 	[Inline Frame] python39.dll!_Py_Dealloc(_object *) Line 2209	C
 	[Inline Frame] python39.dll!_Py_DECREF(_object *) Line 430	C
 	python39.dll!_PyInterpreterState_ClearModules(_is * interp) Line 768	C
 	python39.dll!_PyImport_Cleanup(_ts * tstate) Line 628	C
 	python39.dll!Py_FinalizeEx() Line 1432	C
 	python39.dll!Py_Exit(int sts) Line 2433	C
 	python39.dll!handle_system_exit() Line 696	C
 	python39.dll!_PyErr_PrintEx(_ts * tstate, int set_sys_last_vars) Line 708	C
 	[Inline Frame] python39.dll!PyErr_Print() Line 807	C
 	python39.dll!PyRun_InteractiveLoopFlags(_iobuf * fp, const char * filename_str, PyCompilerFlags * flags) Line 137	C
 	python39.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 81	C
 	python39.dll!pymain_run_stdin(PyConfig * config, PyCompilerFlags * cf) Line 509	C
 	python39.dll!pymain_run_python(int * exitcode) Line 597	C
 	python39.dll!Py_RunMain() Line 675	C
 	python39.dll!Py_Main(int argc, wchar_t * * argv) Line 716	C
 	[External Code]	
```

Locals:
```
-		m	0x000001fbea75ddb0 {ob_base={ob_refcnt=0 ob_type=0x00007fff5a1e5650 {python39.dll!_typeobject PyCFunction_Type} {...} } ...}	PyCFunctionObject *
-		ob_base	{ob_refcnt=0 ob_type=0x00007fff5a1e5650 {python39.dll!_typeobject PyCFunction_Type} {ob_base={ob_base=...} ...} }	_object
		ob_refcnt	0	__int64
-		ob_type	0x00007fff5a1e5650 {python39.dll!_typeobject PyCFunction_Type} {ob_base={ob_base={ob_refcnt=23 ob_type=...} ...} ...}	_typeobject *
+		ob_base	{ob_base={ob_refcnt=23 ob_type=0x00007fff5a1e7c60 {python39.dll!_typeobject PyType_Type} {ob_base={ob_base=...} ...} } ...}	PyVarObject
+		tp_name	0x00007fff5a16d8a0 "builtin_function_or_method"	const char *
		tp_basicsize	56	__int64
		tp_itemsize	0	__int64
		tp_dealloc	0x00007fff59e2c260 {python39.dll!meth_dealloc(PyCFunctionObject *)}	void(*)(_object *)
		tp_vectorcall_offset	48	__int64
		tp_getattr	0x0000000000000000	_object *(*)(_object *, char *)
		tp_setattr	0x0000000000000000	int(*)(_object *, char *, _object *)
+		tp_as_async	0x0000000000000000 <NULL>	PyAsyncMethods *
		tp_repr	0x00007fff59e5c430 {python39.dll!meth_repr(PyCFunctionObject *)}	_object *(*)(_object *)
+		tp_as_number	0x0000000000000000 <NULL>	PyNumberMethods *
+		tp_as_sequence	0x0000000000000000 <NULL>	PySequenceMethods *
+		tp_as_mapping	0x0000000000000000 <NULL>	PyMappingMethods *
		tp_hash	0x00007fff59f44768 {python39.dll!meth_hash(PyCFunctionObject *)}	__int64(*)(_object *)
		tp_call	0x00007fff59e28790 {python39.dll!cfunction_call(_object *, _object *, _object *)}	_object *(*)(_object *, _object *, _object *)
		tp_str	0x00007fff59e5b978 {python39.dll!object_str(_object *)}	_object *(*)(_object *)
		tp_getattro	0x00007fff59e2fc40 {python39.dll!PyObject_GenericGetAttr(_object *, _object *)}	_object *(*)(_object *, _object *)
		tp_setattro	0x00007fff59e92520 {python39.dll!PyObject_GenericSetAttr(_object *, _object *, _object *)}	int(*)(_object *, _object *, _object *)
+		tp_as_buffer	0x0000000000000000 <NULL>	PyBufferProcs *
		tp_flags	808960	unsigned long
+		tp_doc	0x0000000000000000 <NULL>	const char *
		tp_traverse	0x00007fff59eb0eb0 {python39.dll!meth_traverse(PyCFunctionObject *, int(*)(_object *, void *), void *)}	int(*)(_object *, int(*)(_object *, void *), void *)
		tp_clear	0x0000000000000000	int(*)(_object *)
		tp_richcompare	0x00007fff59f653a4 {python39.dll!meth_richcompare(_object *, _object *, int)}	_object *(*)(_object *, _object *, int)
		tp_weaklistoffset	40	__int64
		tp_iter	0x0000000000000000	_object *(*)(_object *)
		tp_iternext	0x0000000000000000	_object *(*)(_object *)
+		tp_methods	0x00007fff5a20dad0 {python39.dll!PyMethodDef meth_methods[2]} {ml_name=0x00007fff5a1673d0 "__reduce__" ...}	PyMethodDef *
+		tp_members	0x00007fff5a20da80 {python39.dll!PyMemberDef meth_members[2]} {name=0x00007fff5a038210 "__module__" ...}	PyMemberDef *
+		tp_getset	0x00007fff5a20d990 {python39.dll!PyGetSetDef meth_getsets[6]} {name=0x00007fff5a038208 "__doc__" get=...}	PyGetSetDef *
+		tp_base	0x00007fff5a1e7e00 {python39.dll!_typeobject PyBaseObject_Type} {ob_base={ob_base={ob_refcnt=10617 ob_type=...} ...} ...}	_typeobject *
+		tp_dict	0x000001fbb3b2a240 {ob_refcnt=1 ob_type=0x00007fff5a1db8b0 {python39.dll!_typeobject PyDict_Type} {ob_base=...} }	_object *
		tp_descr_get	0x0000000000000000	_object *(*)(_object *, _object *, _object *)
		tp_descr_set	0x0000000000000000	int(*)(_object *, _object *, _object *)
		tp_dictoffset	0	__int64
		tp_init	0x00007fff59e26378 {python39.dll!object_init(_object *, _object *, _object *)}	int(*)(_object *, _object *, _object *)
		tp_alloc	0x00007fff59e98130 {python39.dll!PyType_GenericAlloc(_typeobject *, __int64)}	_object *(*)(_typeobject *, __int64)
		tp_new	0x0000000000000000	_object *(*)(_typeobject *, _object *, _object *)
		tp_free	0x00007fff59e2c610 {python39.dll!PyObject_GC_Del(void *)}	void(*)(void *)
		tp_is_gc	0x0000000000000000	int(*)(_object *)
+		tp_bases	0x000001fbb3b04910 {ob_refcnt=1 ob_type=0x00007fff5a1e7920 {python39.dll!_typeobject PyTuple_Type} {...} }	_object *
+		tp_mro	0x000001fbb3b2a400 {ob_refcnt=1 ob_type=0x00007fff5a1e7920 {python39.dll!_typeobject PyTuple_Type} {...} }	_object *
+		tp_cache	0x0000000000000000 <NULL>	_object *
+		tp_subclasses	0x000001fbb3b2a4c0 {ob_refcnt=1 ob_type=0x00007fff5a1db8b0 {python39.dll!_typeobject PyDict_Type} {ob_base=...} }	_object *
+		tp_weaklist	0x000001fbb3b29db0 {ob_refcnt=1 ob_type=0x00007fff5a1e8620 {python39.dll!_typeobject _PyWeakref_RefType} {...} }	_object *
		tp_del	0x0000000000000000	void(*)(_object *)
		tp_version_tag	40	unsigned int
		tp_finalize	0x0000000000000000	void(*)(_object *)
		tp_vectorcall	0x0000000000000000	_object *(*)(_object *, _object * const *, unsigned __int64, _object *)
-		m_ml	0x000001fbe8ec3fe0 {ml_name=??? ml_meth=??? ml_flags=??? ...}	PyMethodDef *
		ml_name	<Unable to read memory>	
		ml_meth	<Unable to read memory>	
		ml_flags	<Unable to read memory>	
		ml_doc	<Unable to read memory>	
-		m_self	0x000001fbea74eed0 {ob_refcnt=2181481948096 ob_type=0x00007fff5a1da1f0 {python39.dll!_typeobject PyCapsule_Type} {...} }	_object *
		ob_refcnt	2181481948096	__int64
-		ob_type	0x00007fff5a1da1f0 {python39.dll!_typeobject PyCapsule_Type} {ob_base={ob_base={ob_refcnt=3 ob_type=...} ...} ...}	_typeobject *
+		ob_base	{ob_base={ob_refcnt=3 ob_type=0x00007fff5a1e7c60 {python39.dll!_typeobject PyType_Type} {ob_base={ob_base=...} ...} } ...}	PyVarObject
+		tp_name	0x00007fff5a16bb68 "PyCapsule"	const char *
		tp_basicsize	48	__int64
		tp_itemsize	0	__int64
		tp_dealloc	0x00007fff59f3c880 {python39.dll!capsule_dealloc(_object *)}	void(*)(_object *)
		tp_vectorcall_offset	0	__int64
		tp_getattr	0x0000000000000000	_object *(*)(_object *, char *)
		tp_setattr	0x0000000000000000	int(*)(_object *, char *, _object *)
+		tp_as_async	0x0000000000000000 <NULL>	PyAsyncMethods *
		tp_repr	0x00007fff5a00093c {python39.dll!capsule_repr(_object *)}	_object *(*)(_object *)
+		tp_as_number	0x0000000000000000 <NULL>	PyNumberMethods *
+		tp_as_sequence	0x0000000000000000 <NULL>	PySequenceMethods *
+		tp_as_mapping	0x0000000000000000 <NULL>	PyMappingMethods *
		tp_hash	0x00007fff59e93c1c {python39.dll!_Py_HashPointer(const void *)}	__int64(*)(_object *)
		tp_call	0x0000000000000000	_object *(*)(_object *, _object *, _object *)
		tp_str	0x00007fff59e5b978 {python39.dll!object_str(_object *)}	_object *(*)(_object *)
		tp_getattro	0x00007fff59e2fc40 {python39.dll!PyObject_GenericGetAttr(_object *, _object *)}	_object *(*)(_object *, _object *)
		tp_setattro	0x00007fff59e92520 {python39.dll!PyObject_GenericSetAttr(_object *, _object *, _object *)}	int(*)(_object *, _object *, _object *)
+		tp_as_buffer	0x0000000000000000 <NULL>	PyBufferProcs *
		tp_flags	4096	unsigned long
+		tp_doc	0x00007fff5a122650 "Capsule objects let you wrap a C \"void *\" pointer in a Python\nobject.  They're a way of passing data through the Python interpreter\nwithout creating your own custom type.\n\nCapsules are used for commun...	const char *
		tp_traverse	0x0000000000000000	int(*)(_object *, int(*)(_object *, void *), void *)
		tp_clear	0x0000000000000000	int(*)(_object *)
		tp_richcompare	0x00007fff59e839c4 {python39.dll!object_richcompare(_object *, _object *, int)}	_object *(*)(_object *, _object *, int)
		tp_weaklistoffset	0	__int64
		tp_iter	0x0000000000000000	_object *(*)(_object *)
		tp_iternext	0x0000000000000000	_object *(*)(_object *)
+		tp_methods	0x0000000000000000 <NULL>	PyMethodDef *
+		tp_members	0x0000000000000000 <NULL>	PyMemberDef *
+		tp_getset	0x0000000000000000 <NULL>	PyGetSetDef *
+		tp_base	0x00007fff5a1e7e00 {python39.dll!_typeobject PyBaseObject_Type} {ob_base={ob_base={ob_refcnt=10617 ob_type=...} ...} ...}	_typeobject *
+		tp_dict	0x000001fbb3b2d780 {ob_refcnt=1 ob_type=0x00007fff5a1db8b0 {python39.dll!_typeobject PyDict_Type} {ob_base=...} }	_object *
		tp_descr_get	0x0000000000000000	_object *(*)(_object *, _object *, _object *)
		tp_descr_set	0x0000000000000000	int(*)(_object *, _object *, _object *)
		tp_dictoffset	0	__int64
		tp_init	0x00007fff59e26378 {python39.dll!object_init(_object *, _object *, _object *)}	int(*)(_object *, _object *, _object *)
		tp_alloc	0x00007fff59e98130 {python39.dll!PyType_GenericAlloc(_typeobject *, __int64)}	_object *(*)(_typeobject *, __int64)
		tp_new	0x0000000000000000	_object *(*)(_typeobject *, _object *, _object *)
		tp_free	0x00007fff59e50cd0 {python39.dll!PyObject_Free(void *)}	void(*)(void *)
		tp_is_gc	0x0000000000000000	int(*)(_object *)
+		tp_bases	0x000001fbb3b04b50 {ob_refcnt=1 ob_type=0x00007fff5a1e7920 {python39.dll!_typeobject PyTuple_Type} {...} }	_object *
+		tp_mro	0x000001fbb3b2d7c0 {ob_refcnt=1 ob_type=0x00007fff5a1e7920 {python39.dll!_typeobject PyTuple_Type} {...} }	_object *
+		tp_cache	0x0000000000000000 <NULL>	_object *
+		tp_subclasses	0x0000000000000000 <NULL>	_object *
+		tp_weaklist	0x000001fbb3b2f090 {ob_refcnt=1 ob_type=0x00007fff5a1e8620 {python39.dll!_typeobject _PyWeakref_RefType} {...} }	_object *
		tp_del	0x0000000000000000	void(*)(_object *)
		tp_version_tag	0	unsigned int
		tp_finalize	0x0000000000000000	void(*)(_object *)
		tp_vectorcall	0x0000000000000000	_object *(*)(_object *, _object * const *, unsigned __int64, _object *)
-		m_module	0x000001fbea75e3f0 {ob_refcnt=9 ob_type=0x00007fff5a1e8140 {python39.dll!_typeobject PyUnicode_Type} {...} }	_object *
		ob_refcnt	9	__int64
-		ob_type	0x00007fff5a1e8140 {python39.dll!_typeobject PyUnicode_Type} {ob_base={ob_base={ob_refcnt=495 ob_type=...} ...} ...}	_typeobject *
+		ob_base	{ob_base={ob_refcnt=495 ob_type=0x00007fff5a1e7c60 {python39.dll!_typeobject PyType_Type} {ob_base={...} ...} } ...}	PyVarObject
+		tp_name	0x00007fff5a036c8c "str"	const char *
		tp_basicsize	80	__int64
		tp_itemsize	0	__int64
		tp_dealloc	0x00007fff59e2c830 {python39.dll!unicode_dealloc(_object *)}	void(*)(_object *)
		tp_vectorcall_offset	0	__int64
		tp_getattr	0x0000000000000000	_object *(*)(_object *, char *)
		tp_setattr	0x0000000000000000	int(*)(_object *, char *, _object *)
+		tp_as_async	0x0000000000000000 <NULL>	PyAsyncMethods *
		tp_repr	0x00007fff59ea4cac {python39.dll!unicode_repr(_object *)}	_object *(*)(_object *)
+		tp_as_number	0x00007fff5a20f9f0 {python39.dll!PyNumberMethods unicode_as_number} {nb_add=0x0000000000000000 nb_subtract=...}	PyNumberMethods *
+		tp_as_sequence	0x00007fff5a20f8c0 {python39.dll!PySequenceMethods unicode_as_sequence} {sq_length=0x00007fff59e6c498 {python39.dll!unicode_length(_object *)} ...}	PySequenceMethods *
+		tp_as_mapping	0x00007fff5a20f950 {python39.dll!PyMappingMethods unicode_as_mapping} {mp_length=0x00007fff59e6c498 {python39.dll!unicode_length(_object *)} ...}	PyMappingMethods *
		tp_hash	0x00007fff59e95970 {python39.dll!unicode_hash(_object *)}	__int64(*)(_object *)
		tp_call	0x0000000000000000	_object *(*)(_object *, _object *, _object *)
		tp_str	0x00007fff59ea68c0 {python39.dll!unicode_str(_object *)}	_object *(*)(_object *)
		tp_getattro	0x00007fff59e2fc40 {python39.dll!PyObject_GenericGetAttr(_object *, _object *)}	_object *(*)(_object *, _object *)
		tp_setattro	0x00007fff59e92520 {python39.dll!PyObject_GenericSetAttr(_object *, _object *, _object *)}	int(*)(_object *, _object *, _object *)
+		tp_as_buffer	0x0000000000000000 <NULL>	PyBufferProcs *
		tp_flags	269227008	unsigned long
+		tp_doc	0x00007fff5a141740 "str(object='') -> str\nstr(bytes_or_buffer[, encoding[, errors]]) -> str\n\nCreate a new string object from the given object. If encoding or\nerrors is specified, then the object must expose a data buffer...	const char *
		tp_traverse	0x0000000000000000	int(*)(_object *, int(*)(_object *, void *), void *)
		tp_clear	0x0000000000000000	int(*)(_object *)
		tp_richcompare	0x00007fff59e828a0 {python39.dll!PyUnicode_RichCompare(_object *, _object *, int)}	_object *(*)(_object *, _object *, int)
		tp_weaklistoffset	0	__int64
		tp_iter	0x00007fff59ea7618 {python39.dll!unicode_iter(_object *)}	_object *(*)(_object *)
		tp_iternext	0x0000000000000000	_object *(*)(_object *)
+		tp_methods	0x00007fff5a20fb70 {python39.dll!PyMethodDef unicode_methods[51]} {ml_name=0x00007fff5a039c58 "encode" ...}	PyMethodDef *
+		tp_members	0x0000000000000000 <NULL>	PyMemberDef *
+		tp_getset	0x0000000000000000 <NULL>	PyGetSetDef *
+		tp_base	0x00007fff5a1e7e00 {python39.dll!_typeobject PyBaseObject_Type} {ob_base={ob_base={ob_refcnt=10617 ob_type=...} ...} ...}	_typeobject *
+		tp_dict	0x000001fbb3b19a40 {ob_refcnt=1 ob_type=0x00007fff5a1db8b0 {python39.dll!_typeobject PyDict_Type} {ob_base=...} }	_object *
		tp_descr_get	0x0000000000000000	_object *(*)(_object *, _object *, _object *)
		tp_descr_set	0x0000000000000000	int(*)(_object *, _object *, _object *)
		tp_dictoffset	0	__int64
		tp_init	0x00007fff59e26378 {python39.dll!object_init(_object *, _object *, _object *)}	int(*)(_object *, _object *, _object *)
		tp_alloc	0x00007fff59e98130 {python39.dll!PyType_GenericAlloc(_typeobject *, __int64)}	_object *(*)(_typeobject *, __int64)
		tp_new	0x00007fff59e263d8 {python39.dll!unicode_new(_typeobject *, _object *, _object *)}	_object *(*)(_typeobject *, _object *, _object *)
		tp_free	0x00007fff59e50cd0 {python39.dll!PyObject_Free(void *)}	void(*)(void *)
		tp_is_gc	0x0000000000000000	int(*)(_object *)
+		tp_bases	0x000001fbb3b04610 {ob_refcnt=1 ob_type=0x00007fff5a1e7920 {python39.dll!_typeobject PyTuple_Type} {...} }	_object *
+		tp_mro	0x000001fbb3b19cc0 {ob_refcnt=1 ob_type=0x00007fff5a1e7920 {python39.dll!_typeobject PyTuple_Type} {...} }	_object *
+		tp_cache	0x0000000000000000 <NULL>	_object *
+		tp_subclasses	0x000001fbb94c5f00 {ob_refcnt=1 ob_type=0x00007fff5a1db8b0 {python39.dll!_typeobject PyDict_Type} {ob_base=...} }	_object *
+		tp_weaklist	0x000001fbb3b1fe50 {ob_refcnt=1 ob_type=0x00007fff5a1e8620 {python39.dll!_typeobject _PyWeakref_RefType} {...} }	_object *
		tp_del	0x0000000000000000	void(*)(_object *)
		tp_version_tag	4	unsigned int
		tp_finalize	0x0000000000000000	void(*)(_object *)
		tp_vectorcall	0x0000000000000000	_object *(*)(_object *, _object * const *, unsigned __int64, _object *)
-		m_weakreflist	0x0000000000000000 <NULL>	_object *
		ob_refcnt	<Unable to read memory>	
		ob_type	<Unable to read memory>	
		vectorcall	0x0000000000000000	_object *(*)(_object *, _object * const *, unsigned __int64, _object *)

```

----------
components: Interpreter Core, Windows
messages: 373279
nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Access violation in python39.dll!meth_dealloc on exit
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41237>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:12:06 2020
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 08 Jul 2020 06:12:06 +0000
Subject: [issue41237] Access violation in python39.dll!meth_dealloc on exit
In-Reply-To: <1594188565.24.0.738467793313.issue41237@roundup.psfhosted.org>
Message-ID: <1594188726.17.0.755911513528.issue41237@roundup.psfhosted.org>


Change by Christoph Gohlke <cgohlke at uci.edu>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41237>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:26:34 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 08 Jul 2020 06:26:34 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594189594.97.0.100803712754.issue22239@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> 90% of everything people are doing here are in the context of HTTP services.   The problem of, "something.a now creates state that other tasks might see" is not a real "problem" that is solved by using IO-only explicit context switching.  This is because in a CRUD-style application, "something" is not going to be a process-local yet thread-global object that had to be created specifically for the application (there's things like the database connection pool and some registries that the ORM uses, but those problems are taken care of and aren't specific to one particular application).

Yeah, in classic HTTP CRUD services the concurrency is just a bunch of stateless handlers running simultaneously. This is about the simplest possible kind of concurrency. There are times when async is useful here, but to me the main motivation for async is for building applications with more complex concurrency, that currently just don't get written because of the lack of good frameworks. So that 90% number might be accurate for right now, but I'm not sure it's accurate for the future.

> In the realm of Python HTTP/CRUD applications, async is actually very popular however it is in the form of gevent and sometimes eventlet monkeypatching, often because people are using async web servers like gunicorn.

A critical difference between gevent-style async and newer frameworks like asyncio and trio is that the newer frameworks put cancellation support much more in the foreground. To me cancellation is the strongest argument for 'await' syntax, so I'm not sure experience with gevent is representative.

I am a bit struck that you haven't mentioned cancellation handling at all in your replies. I can't emphasize enough how much cancellation requires care and attention throughout the whole ecosystem.

> w.r.t the issue of writing everything as async and then using the coroutine primitives to convert to "sync" as means of maintaining both facades, I don't think that covers the fact that most DBAPI drivers are sync only

I think I either disagree or am missing something :-). Certainly for both edgedb and urllib3, when they're running in sync mode, they end up using synchronous network APIs at the "bottom", and it works fine.

The greenlet approach does let you skip adding async/await annotations to your code, so it saves some work that way. IME this isn't particularly difficult (you probably don't need to change any logic at all, just add some extra annotations), and to me the benefits outweigh that, but I can see how you might prefer greenlets either temporarily as a transition hack or even in the long term.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:33:52 2020
From: report at bugs.python.org (pmp-p)
Date: Wed, 08 Jul 2020 06:33:52 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594190032.35.0.361929928085.issue22239@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:42:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jul 2020 06:42:47 +0000
Subject: [issue41232] Python `functools.wraps` doesn't deal with defaults
 correctly
In-Reply-To: <1594159222.49.0.432639092165.issue41232@roundup.psfhosted.org>
Message-ID: <1594190567.79.0.622602753761.issue41232@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41232>
_______________________________________

From report at bugs.python.org  Wed Jul  8 02:57:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jul 2020 06:57:03 +0000
Subject: [issue21041] pathlib.PurePath.parents rejects negative indexes
In-Reply-To: <1395613011.22.0.29152070109.issue21041@psf.upfronthosting.co.za>
Message-ID: <1594191423.97.0.0636093967177.issue21041@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maxwell, in your case a more correct and obvious way is

    Path('/tmp') in filepath.parents

although it may be not very efficient. Using the is_relative_to() method may be more efficient and obvious.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21041>
_______________________________________

From report at bugs.python.org  Wed Jul  8 03:11:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jul 2020 07:11:26 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594192286.49.0.639098415653.issue39542@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not know the purpose of this issue. The new code does not look cleaner to me, but maybe it is only for me.

But performance regressions should be fixed. We cannot rely on compiler-specific global optimization, which is hard to test and does not work for dynamic linkage (third-party extensions and applications with built-in Python). Even "inline" is just a hint to the compiler and does not guarantee inlining the code.

Raymond's suggestions look reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Wed Jul  8 03:32:16 2020
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 08 Jul 2020 07:32:16 +0000
Subject: [issue41237] Access violation in python39.dll!meth_dealloc on exit
In-Reply-To: <1594188565.24.0.738467793313.issue41237@roundup.psfhosted.org>
Message-ID: <1594193536.35.0.305410288106.issue41237@roundup.psfhosted.org>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

I tracked this to an import of the numba-0.50.1 package during the numpy tests. `python -c"import numba'` is enough to reproduce this crash during interpreter exit. Probably the package needs to be ported to Python 3.9.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41237>
_______________________________________

From report at bugs.python.org  Wed Jul  8 03:32:47 2020
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Miech?=)
Date: Wed, 08 Jul 2020 07:32:47 +0000
Subject: [issue41238] Python 3 shelve.DbfilenameShelf is generating 164 times
 larger files than Python 2.7 when storing dicts
Message-ID: <1594193566.99.0.171960738347.issue41238@roundup.psfhosted.org>


New submission from Pawe? Miech <pawelmhm at gmail.com>:

I'm porting some code from Python 2.7 to Python 3.8. There is some code that is using shelve.DbfilenameShelf to store some nested dictionaries with sets. I found out that compared with Python 2.7 Python 3.8 shelve generates files that are approximately 164 larger on disk. Python 3.8 file is 2 027 520 size, when Python 2.7 size is 12 288.

Code sample:
Filename: test_anydbm.py

#!/usr/bin/env python
import datetime
import shelve
import sys
import time
from os import path


def main():
    print(sys.version)
    fname = 'shelf_test_{}'.format(datetime.datetime.now().isoformat())
    bucket = shelve.DbfilenameShelf(fname, "n")
    now = time.time()
    limit = 1000
    key = 'some key > some key > other'
    top_dict = {}
    to_store = {
        1: {
            'page_item_numbers': set(),
            'products_on_page': None
        }
    }
    for i in range(limit):
        to_store[1]['page_item_numbers'].add(i)
        top_dict[key] = to_store
        bucket[key] = top_dict
    end = time.time()
    db_file = False
    try:
        fsize = path.getsize(fname)
    except Exception as e:
        print("file not found? {}".format(e))
        try:
            fsize = path.getsize(fname + '.db')
            db_file = True
        except Exception as e:
            print("file not found? {}".format(e))
            fsize = None
    print("Stored {} in {} filesize {}".format(limit, end - now, fsize))
    print(fname)
    bucket.close()
    bucket = shelve.DbfilenameShelf(fname, flag="r")
    if db_file:
        fname += '.db'
    print("In file {} {}".format(fname, len(list(bucket.items()))))

Output of running it in docker image:

Dockerfile:
FROM python:2-jessie
VOLUME /scripts
CMD scripts/test_anydbm.py

2.7.16 (default, Jul 10 2019, 03:39:20) 
[GCC 4.9.2]
Stored 1000 in 0.0814290046692 filesize 12288
shelf_test_2020-07-08T07:26:23.778769
In file shelf_test_2020-07-08T07:26:23.778769 1


So you can see file size: 12 288

And now running same thing in Python 3

Dockerfile:

FROM python:3.8-slim-buster
VOLUME /scripts
CMD scripts/test_anydbm.py

3.8.3 (default, Jun  9 2020, 17:49:41) 
[GCC 8.3.0]
Stored 1000 in 0.02681446075439453 filesize 2027520
shelf_test_2020-07-08T07:27:18.068638
In file shelf_test_2020-07-08T07:27:18.068638 1

Notice file size: 2 027 520

Why is this happening? Is this a bug? If I'd like to fix it, do you have some ideas about causes of this?

----------
components: Library (Lib)
files: test_anydbm.py
messages: 373284
nosy: Pawe? Miech
priority: normal
severity: normal
status: open
title: Python 3 shelve.DbfilenameShelf is generating 164 times larger files than Python 2.7 when storing dicts
type: resource usage
versions: Python 3.8
Added file: https://bugs.python.org/file49304/test_anydbm.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41238>
_______________________________________

From report at bugs.python.org  Wed Jul  8 03:55:58 2020
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 08 Jul 2020 07:55:58 +0000
Subject: [issue41237] Access violation in python39.dll!meth_dealloc on exit
In-Reply-To: <1594188565.24.0.738467793313.issue41237@roundup.psfhosted.org>
Message-ID: <1594194958.43.0.179577389459.issue41237@roundup.psfhosted.org>


Change by Christoph Gohlke <cgohlke at uci.edu>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41237>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:03:26 2020
From: report at bugs.python.org (Itay azolay)
Date: Wed, 08 Jul 2020 08:03:26 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594195406.88.0.908512397178.issue41220@roundup.psfhosted.org>


Itay azolay <itayazolay at gmail.com> added the comment:

Thanks, you have some very good points.
Let my try to address them

* cache functions really are expected to be cheap, but what they really need to be is *cheaper*. If my computation is expensive enough, I might be okay with making a less, still somewhat expensive computation instead. I believe it's for the developer to decide.

* key is usually used in a sequence of elements contexts, but it is expected to run multiple times. I believe that this is expected(what else could someone expect to happen?). I believe this is solvable through good docs(or change the name of the parameter?) 

* I believe that a matching signature key-make function is a good thing. It will enforce the user to address the key-make function if he changes the behaviour of the cached function, and he would rethink the cache, otherwise it will not work.

* I can't argue about API simplicity, you probably have much more experience there. However, I believe that if we can agree that this is a useful feature, we can find a way to make the API clear and welcoming.
BTW, I agree with the problems with the typed argument, never quite understood when can this be useful.

I'd like to compare the key argument suggested here, to key argument through other python functions. let's take `sorted` as example.
sorted supports key to be able to sort other types of data structures,
even though I like your suggestion, to use dataclass, I believe that if it's applicable here, we can say the same thing for sorted.
we could require sorted to work the same way:

@total_ordering # If I'm not mistaken
@dataclass
class MyData:
   ...
   fields
   ...
   def __gt__(self, other):
     return self.field > other.field

sorted(MyData(my_data_instance))


I think we both see the reason why this wouldn't be optimal in some cases here.
Without the key function, the sorted function doesn't support a big part of python objects.
I think the same applies for LRU cache. Right now, we just can use it with all python objects. we have to change the API, the way we move data around, the way we keep our objects, just so that lru_cache would work.
And after all that, lru_cache will just break if someone send some data in a list instead of tuple. I think that cause a lot of developers to give up the default stdlib lru_cache.

In my case, I have a few list of lists, each list indicates an event that happened. In each event, there is a unique timestamp. 
I have an object, that have few different lists
class Myobj:
    events_1: List[list]
    events_2: List[list]


I have a small, esoteric function, that looks like that now:
def calc(list_of_events):
  # calculation
  pass

and is being called from multiple places in the code, which takes a lot of time, like that
calc(events_1) # multiple times
calc(events_2) # multiple times

I wanted to cache the function calc, but now I have to do something like that:
@lru_cache
def calc_events_1(myobj):
  calc(myobj.events_1)

@lru_cache
def calc_events_2(myobj):
  calc(myobj.events_2)

right now I can't change the API of the lists, because they are being used in multiple places, some of this least(I have multiple events-lists) are being converted to numpy, some doesn't.

Regarding API, we could make it simpler by either use must have kwargs, like lru_cache(maxsize, typed, *, key=None)
or, like the property setters/getters case
lru_cache
def function(args, ...):
  pass
@function.make_key # or key, whatever name is good
def _(args, ...):
  return new_key

However I like the second option less.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:22:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 08:22:56 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594196576.13.0.187997023696.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +20536
pull_request: https://github.com/python/cpython/pull/21390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:27:07 2020
From: report at bugs.python.org (Wu Wenyan)
Date: Wed, 08 Jul 2020 08:27:07 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
Message-ID: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>


New submission from Wu Wenyan <wuwy.fnst at cn.fujitsu.com>:

I am running the following code in python3.6 to connect to a storage.
[root at controller wuwy]# python3
Python 3.6.8 (default, Jan 11 2019, 02:17:16)
[GCC 8.2.1 20180905 (Red Hat 8.2.1-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywbem
>>> ip = '193.168.11.113'
>>> user = '193_160_28_29'
>>> password = '193_160_28_29'
>>> url = 'https://193.168.11.113:5989'
>>> ca_certs = '/home/ca.cer'
>>> conn = pywbem.WBEMConnection(url,(user, password),default_namespace='root/example',ca_certs=ca_certs,no_verification=False)
>>> conn.EnumerateInstances('EXAMPLE_StorageProduct')

And I am getting the below error.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_operations.py", line 1919, in EnumerateInstances
    **extra)
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_operations.py", line 1232, in _imethodcall
    conn_id=self.conn_id)
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_http.py", line 776, in wbem_request
    client.endheaders()
  File "/usr/lib64/python3.6/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.6/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_http.py", line 461, in send
    self.connect()  # pylint: disable=no-member
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_http.py", line 619, in connect
    return self.sock.connect((self.host, self.port))
  File "/usr/lib64/python3.6/ssl.py", line 1064, in connect
    self._real_connect(addr, False)
  File "/usr/lib64/python3.6/ssl.py", line 1055, in _real_connect
    self.do_handshake()
  File "/usr/lib64/python3.6/ssl.py", line 1032, in do_handshake
    self._sslobj.do_handshake()
  File "/usr/lib64/python3.6/ssl.py", line 648, in do_handshake
    raise ValueError("check_hostname needs server_hostname "
ValueError: check_hostname needs server_hostname argument

When I am running the same code in python3.7, error changed.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/python3/lib/python3.7/site-packages/pywbem/_cim_operations.py", line 2494, in EnumerateInstances
    **extra)
  File "/usr/python3/lib/python3.7/site-packages/pywbem/_cim_operations.py", line 1763, in _imethodcall
    conn_id=self.conn_id)
  File "/usr/python3/lib/python3.7/site-packages/pywbem/_cim_http.py", line 824, in wbem_request
    client.endheaders()
  File "/usr/python3/lib/python3.7/http/client.py", line 1224, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/python3/lib/python3.7/http/client.py", line 1016, in _send_output
    self.send(msg)
  File "/usr/python3/lib/python3.7/site-packages/pywbem/_cim_http.py", line 483, in send
    self.connect()  # pylint: disable=no-member
  File "/usr/python3/lib/python3.7/site-packages/pywbem/_cim_http.py", line 661, in connect
    conn_id=conn_id)
pywbem._exceptions.ConnectionError: SSL error <class 'ssl.SSLCertVerificationError'>: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address mismatch, certificate is not valid for '193.168.11.113'. (_ssl.c:1045); OpenSSL version: OpenSSL 1.1.1c FIPS  28 May 2019

This code works fine with python2.7 version.

And I checked the CN and SAN of the certificate, seems no problem here.

So could anyone tell me what's the problem here?

----------
assignee: christian.heimes
components: SSL
files: 19316811113.crt
messages: 373286
nosy: Chirs, christian.heimes
priority: normal
severity: normal
status: open
title: SSL Certificate verify failed in Python3.6/3.7
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49305/19316811113.crt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:29:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jul 2020 08:29:17 +0000
Subject: [issue41221] io.TextIOWrapper ignores silently partial write if
 buffer is unbuffered
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594196957.59.0.393321990532.issue41221@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oh, this is a serious problem.

AFAIK TextIOWrapper initially supported only buffered writers, but the support of non-buffered writers was added later. We can make TextIOWrapper calling write() of underlying binary stream repeatedly, but it will break the code which uses TextIOWrapper with other file-like objects whose write() method does not return the number of written bytes. For example:

    buffer = []
    class Writer: write = buffer.append
    t = TextIOWrapper(Writer())

Even if we fix writing sys.stdout and sys.stderr there will be a problem with programs which write directly to sys.stdout.buffer or use open(buffering=0).

This is a complex issue and it needs a complex solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:30:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 08:30:06 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594197006.21.0.0282025578145.issue39542@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Since the PEP 620 is still a draft, I created PR 21390 to fix the performance issue.

As I wrote, I didn't expect any impact on performances since I added _PyType_HasFeature() which access directly the structure member. But I was wrong. 

This change is not strictly required by my work for now, so I just revert it until the PEP is accepted.

If I reapply the change later, I will take care of ensuring that it's properly optimized in CPython internals (access the member, don't call a function), especially on macOS.

If you want to continue the discussion, please discuss on bpo-40170, since this issue is unrelated.


Stefan Krah:
> This one I have some trouble with. It cites PyPy as a bottleneck,
> but IIRC Armin Rigo was on record saying that such changes would
> not help PyPy, and he would come up with a counter proposal.
> Has this changed?

Raymond:
> Victor, is there any reason PyType_GetFlags() can't be converted to a macro or an inlined function?

Serhiy Storchaka:
> I do not know the purpose of this issue. The new code does not look cleaner to me, but maybe it is only for me.

I explained the rationale in bpo-40170 and PEP 620.

It's not a "cleanup change". Serhiy: we are discussing the commit 45ec5b99aefa54552947049086e87ec01bc2fc9a of bpo-40170.

This discussion is happening in the wrong bpo which seems to confuse people. So I close again this issue which is fixed.

----------
priority: release blocker -> 
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:32:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 08:32:24 +0000
Subject: [issue41221] io.TextIOWrapper ignores silently partial write if
 buffer is unbuffered
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594197144.59.0.966425999358.issue41221@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> but it will break the code which uses TextIOWrapper with other file-like objects whose write() method does not return the number of written bytes.

We can detect if write() doesn't return an integer and don't attempt to call write() in a loop (until all bytes are written) in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:34:57 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 08 Jul 2020 08:34:57 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594197297.27.0.954603382116.issue41239@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Are you running Python 2.7 on RHEL 7? Python 2.7 on RHEL 7 does not very certs by defaults, see https://access.redhat.com/articles/2039753

Could you please post the output of 'openssl x509 -text -in path/to/cert' for your certificate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:35:46 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Jul 2020 08:35:46 +0000
Subject: [issue41236] "about" button in MacOS caused an error
In-Reply-To: <1594188316.81.0.4505690312.issue41236@roundup.psfhosted.org>
Message-ID: <1594197346.65.0.734791819614.issue41236@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Please say exactly how you reproduced this behavior.  Please paste the results of running the following command from a terminal window:

python3.7 -m test.pythoninfo

replacing python3.7 with whatever you use to start the python that fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41236>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:53:37 2020
From: report at bugs.python.org (Wu Wenyan)
Date: Wed, 08 Jul 2020 08:53:37 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594198417.72.0.128454930618.issue41239@roundup.psfhosted.org>


Wu Wenyan <wuwy.fnst at cn.fujitsu.com> added the comment:

I am running Python on Centos7.
See result in attached file.

----------
Added file: https://bugs.python.org/file49306/server_cer.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:02:41 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 09:02:41 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594198961.74.0.569728233622.issue40170@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +20537
pull_request: https://github.com/python/cpython/pull/21391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:02:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 09:02:36 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594198956.68.0.418824664313.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68 by Victor Stinner in branch 'master':
Revert "bpo-40170: PyType_HasFeature() now always calls PyType_GetFlags() (GH-19378)" (GH-21390)
https://github.com/python/cpython/commit/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:05:06 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 08 Jul 2020 09:05:06 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594199106.75.0.379832992052.issue41239@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Your certificate does not have a subject alternative name extension. CN hostname matching has been deprecated for like 15 years. OpenSSL may ignore the CN and require a proper SAN extension of type IP general name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:06:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 09:06:12 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594199172.07.0.48977398326.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset 45ec5b99aefa54552947049086e87ec01bc2fc9a by Victor Stinner in branch 'master':
> bpo-40170: PyType_HasFeature() now always calls PyType_GetFlags() (GH-19378)

This change causes performance issues on macOS, see discussion starting at:
https://bugs.python.org/issue39542#msg372962

So I reverted the change. I will wait until my PEP 620 is accepted before considering to reapply it.

If it's reapplied, we have to make sure that Python internals currently using PyTuple_Check() still access directly PyTypeObject.tp_flags member. For example, a new _PyTuple_Check() function could be added and uses the internal _PyType_HasFeature() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:08:25 2020
From: report at bugs.python.org (Nghia Minh)
Date: Wed, 08 Jul 2020 09:08:25 +0000
Subject: [issue41240] Use the same kind of quotation mark in f-string
Message-ID: <1594199305.52.0.531988229747.issue41240@roundup.psfhosted.org>


New submission from Nghia Minh <nvmnghia at gmail.com>:

I want to use the same type of quotation mark in f-string, like this:

f'Hey, {' this quote is wrong.'}'

Currently we have to:

f'But, {" this quote is right."}'

----------
components: Library (Lib)
messages: 373296
nosy: Nghia Minh
priority: normal
severity: normal
status: open
title: Use the same kind of quotation mark in f-string
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41240>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:13:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Jul 2020 09:13:03 +0000
Subject: [issue41240] Use the same kind of quotation mark in f-string
In-Reply-To: <1594199305.52.0.531988229747.issue41240@roundup.psfhosted.org>
Message-ID: <1594199583.34.0.294774637774.issue41240@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This is a limitation of the parser: the entire f-string is first evaluated as a string.

Just as 
'Hey, {' this quote is wrong.'}'
or
r'Hey, {' this quote is wrong.'}'
are not valid strings, neither is
f'Hey, {' this quote is wrong.'}'

See issue 33754 for a possible future change that would address this.

----------
nosy: +eric.smith
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41240>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:13:35 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Jul 2020 09:13:35 +0000
Subject: [issue33754] f-strings should be part of the Grammar
In-Reply-To: <1528030778.27.0.592728768989.issue33754@psf.upfronthosting.co.za>
Message-ID: <1594199615.29.0.660950134393.issue33754@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33754>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:16:01 2020
From: report at bugs.python.org (David Caro)
Date: Wed, 08 Jul 2020 09:16:01 +0000
Subject: [issue8814] functools.WRAPPER_ASSIGNMENTS should include
 __annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1594199761.46.0.965275316236.issue8814@roundup.psfhosted.org>


Change by David Caro <david at dcaro.es>:


----------
nosy: +David Caro
nosy_count: 4.0 -> 5.0
pull_requests: +20539
pull_request: https://github.com/python/cpython/pull/21392

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8814>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:16:01 2020
From: report at bugs.python.org (David Caro)
Date: Wed, 08 Jul 2020 09:16:01 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
In-Reply-To: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>
Message-ID: <1594199761.37.0.429913178247.issue41231@roundup.psfhosted.org>


Change by David Caro <david at dcaro.es>:


----------
keywords: +patch
pull_requests: +20538
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21392

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41231>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:19:42 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 09:19:42 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594199982.0.0.55850792076.issue40170@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a0a6f1167834c87f12e2eca11dd77143103e7691 by Miss Islington (bot) in branch '3.9':
Revert "bpo-40170: PyType_HasFeature() now always calls PyType_GetFlags() (GH-19378)" (GH-21390)
https://github.com/python/cpython/commit/a0a6f1167834c87f12e2eca11dd77143103e7691


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:14:33 2020
From: report at bugs.python.org (David Caro)
Date: Wed, 08 Jul 2020 10:14:33 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
In-Reply-To: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>
Message-ID: <1594203273.96.0.676024110731.issue41231@roundup.psfhosted.org>


David Caro <david at dcaro.es> added the comment:

As a note, mypy does not tpyecheck the wrapper functions, probably because it would not be possible with the current code (as the typing hints get lost):

https://mypy.readthedocs.io/en/latest/generics.html?highlight=wrapper#declaring-decorators

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41231>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:18:50 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 08 Jul 2020 10:18:50 +0000
Subject: [issue41221] io.TextIOWrapper ignores silently partial write if
 buffer is unbuffered
In-Reply-To: <1594056833.64.0.146611581422.issue41221@roundup.psfhosted.org>
Message-ID: <1594203530.9.0.891852709831.issue41221@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> it?s probably an even bigger problem on Windows, where writes might be
> limited to 32767 bytes:

This check and workaround in _Py_write_impl doesn't affect disk files and pipes. It only affects character devices for which isatty is true, and really it's only concerned with console screen-buffer files. The workaround is not required in Windows 8.1+, so it can be removed in Python 3.9+.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41221>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:19:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jul 2020 10:19:52 +0000
Subject: [issue40820] Mock Call attributes args and kwargs have no
 changeversion
In-Reply-To: <1590775441.68.0.287476629705.issue40820@roundup.psfhosted.org>
Message-ID: <1594203592.57.0.857491372858.issue40820@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40820>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:20:25 2020
From: report at bugs.python.org (Wu Wenyan)
Date: Wed, 08 Jul 2020 10:20:25 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594203625.33.0.931679962275.issue41239@roundup.psfhosted.org>


Wu Wenyan <wuwy.fnst at cn.fujitsu.com> added the comment:

You are right. I used openssl.cnf when created a csr, and ignore it when created cer.
Now the code works fine with python3.7, but still cannot work in python3.6.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_operations.py", line 1919, in EnumerateInstances
    **extra)
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_operations.py", line 1232, in _imethodcall
    conn_id=self.conn_id)
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_http.py", line 776, in wbem_request
    client.endheaders()
  File "/usr/lib64/python3.6/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.6/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_http.py", line 461, in send
    self.connect()  # pylint: disable=no-member
  File "/usr/local/lib/python3.6/site-packages/pywbem/cim_http.py", line 619, in connect
    return self.sock.connect((self.host, self.port))
  File "/usr/lib64/python3.6/ssl.py", line 1064, in connect
    self._real_connect(addr, False)
  File "/usr/lib64/python3.6/ssl.py", line 1055, in _real_connect
    self.do_handshake()
  File "/usr/lib64/python3.6/ssl.py", line 1032, in do_handshake
    self._sslobj.do_handshake()
  File "/usr/lib64/python3.6/ssl.py", line 648, in do_handshake
    raise ValueError("check_hostname needs server_hostname "
ValueError: check_hostname needs server_hostname argument

Could you please check the attached file for me again?

----------
Added file: https://bugs.python.org/file49307/server_cer_1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:30:15 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 08 Jul 2020 10:30:15 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594204215.61.0.885503137896.issue41239@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's a different issue on 3.6. According to the exception message you are not passing server_hostname to wrap_socket().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:31:08 2020
From: report at bugs.python.org (David Caro)
Date: Wed, 08 Jul 2020 10:31:08 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
In-Reply-To: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>
Message-ID: <1594204268.56.0.169393568203.issue41231@roundup.psfhosted.org>


David Caro <david at dcaro.es> added the comment:

Elaborating on the last message, given the following code:
```
  1 #!/usr/bin/env python3
  2 
  3 from functools import wraps
  4 
  5 
  6 def return_string(wrapped):
  7     @wraps(wrapped)
  8     def wrapper(an_int: int) -> str:
  9         return str(wrapped(an_int))
 10 
 11     return wrapper
 12 
 13 
 14 @return_string
 15 def identity(an_int: int) -> int:
 16     return an_int
 17 
 18 def print_bool(a_bool: bool) -> None:
 19     print(a_bool)
 20 
 21 def identity_nonwrapped(an_int: int) -> int:
 22     return an_int
 23 
 24 
 25 print_bool(a_bool=identity(7))
 26 print_bool(a_bool=identity_nonwrapped(7))
```

mypy will complain only on the last line, being unable to check properly the line 25.

I'll investigate a bit more on why mypy skips that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41231>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:46:33 2020
From: report at bugs.python.org (Wu Wenyan)
Date: Wed, 08 Jul 2020 10:46:33 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594205193.72.0.815340291838.issue41239@roundup.psfhosted.org>


Wu Wenyan <wuwy.fnst at cn.fujitsu.com> added the comment:

I tried to print "self.host" which would be passed to wrap_socket().
It seems no problem.
> /usr/local/lib/python3.6/site-packages/pywbem/cim_http.py(616)connect()
-> try:
(Pdb) p self.host
'193.168.11.113'
(Pdb) n
> /usr/local/lib/python3.6/site-packages/pywbem/cim_http.py(617)connect()
-> self.sock = ctx.wrap_socket(sock,
(Pdb)
> /usr/local/lib/python3.6/site-packages/pywbem/cim_http.py(618)connect()
-> server_hostname=self.host)
(Pdb)
> /usr/local/lib/python3.6/site-packages/pywbem/cim_http.py(619)connect()
-> return self.sock.connect((self.host, self.port))
(Pdb)
ValueError: check_hostname needs server_hostname argument
> /usr/local/lib/python3.6/site-packages/pywbem/cim_http.py(619)connect()
-> return self.sock.connect((self.host, self.port))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:47:59 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 08 Jul 2020 10:47:59 +0000
Subject: [issue41240] Use the same kind of quotation mark in f-string
In-Reply-To: <1594199305.52.0.531988229747.issue41240@roundup.psfhosted.org>
Message-ID: <1594205279.1.0.342310151747.issue41240@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Just change the f string quotes.

Python strings, whether f-strings or not, can be delimited by '' or "" or triple quotes. So this works:


>>> f"But, {'this quote is right.'}"
'But, this quote is right.'

Remember that the part of the f-string is evaluated as code, converted to a string, and interpolated into the rest of the f-string body. This is why the quotes disappear.

If you need both kinds of quotes, use triple-quotes as the delimiter:

>>> f"""Both {'single and "double" quotes'.title()}"""
'Both Single And "Double" Quotes'

I assume you want to pass the '' string to a function or something, and this example is just a simplified version. Because if there is no function call needed, you should just use a regular string, there's no need for an f-string:

"But, 'this quote is right.'"

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41240>
_______________________________________

From report at bugs.python.org  Wed Jul  8 06:51:18 2020
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Miech?=)
Date: Wed, 08 Jul 2020 10:51:18 +0000
Subject: [issue41238] Python 3 shelve.DbfilenameShelf is generating 164 times
 larger files than Python 2.7 when storing dicts
In-Reply-To: <1594193566.99.0.171960738347.issue41238@roundup.psfhosted.org>
Message-ID: <1594205478.69.0.328009553594.issue41238@roundup.psfhosted.org>


Pawe? Miech <pawelmhm at gmail.com> added the comment:

Ok so I see this is an issue that involves the way Pickle pickles Python set objects. Updated script to reproduce appended. Apparently, sets are becoming much larger when stored in Python3 pickle.

----------
Added file: https://bugs.python.org/file49308/test_anydbm.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41238>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:12:26 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Wed, 08 Jul 2020 13:12:26 +0000
Subject: [issue37322] test_ssl: test_pha_required_nocert() emits a
 ResourceWarning
In-Reply-To: <1560803734.85.0.206698450732.issue37322@roundup.psfhosted.org>
Message-ID: <1594213946.56.0.677265377257.issue37322@roundup.psfhosted.org>


Change by Matthew Hughes <matthewhughes934 at gmail.com>:


----------
pull_requests: +20541
pull_request: https://github.com/python/cpython/pull/21393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37322>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:28:48 2020
From: report at bugs.python.org (mike bayer)
Date: Wed, 08 Jul 2020 13:28:48 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594214928.58.0.522189116069.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

as far as cancellation, I gather you're referring to what in gevent / greenlet is the GreenletExit exception.  Sure, that thing is a PITA.   Hence we're all working to provide asyncio frontends and networking backends so that the effects of cancellation I (handwavy handwavy) believe would work smoothly as long as the middle part is done right.   cancellation is likely a more prominent issue with HTTP requests and responses because users are hitting their browser stop buttons all the time.  With databases this typically is within the realm of network partitioning or service restarts, or if the driver is screwing up in some way which with the monkeypatching thing is more likely, but "cancellation" from a database perspective is not the constant event that I think it would be in an HTTP perspective.


> I think I either disagree or am missing something :-). Certainly for both edgedb and urllib3, when they're running in sync mode, they end up using synchronous network APIs at the "bottom", and it works fine.

OK it took me a minute to understand what you're saying, which is, if we are doing the coroutine.send() thing you illustrated below, we're not in an event loop anyway so we can just call blocking code.   OK I did not understand that.  I haven't looked at the coroutine internals through all of this (which is part of my original assertion that I should not have been the person proposing this whole greenlet thing anyway :) ).

Why did urllib3 write unasync?  https://pypi.org/project/unasync/    strictly so they can have a python 2 codebase and that's it?   

SQLAlchemy goes python 3 only in version 2.0.  I did bench the coro example against a non-coro example and it's 3x slower likely due to the StopIteration but as mentioned earlier if this is only once per front-to-back then it would not amount to anything in context.   Still, the risk factor of a rewrite like that, where risk encompasses just all the dumb mistakes and bugs that would be introduced by rewriting everything, does not seem worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:43:57 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 08 Jul 2020 13:43:57 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a ValueError
 instead of an ImportError
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1594215837.92.0.660849735431.issue16396@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +20542
pull_request: https://github.com/python/cpython/pull/21394

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:50:42 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 08 Jul 2020 13:50:42 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594216242.11.0.66821866335.issue41239@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm afraid I have to close this issue as OUT-OF-DATE. It's either a bug in pywbem or a 3.6-only bug. Python 3.6 is in security maintenance mode and no longer receive bug fixes.

I suggest that you take this issue to pywbem bug tracker and get assistance there.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:09:39 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 08 Jul 2020 14:09:39 +0000
Subject: [issue41073] [C API] PyType_GetSlot() should accept static types
In-Reply-To: <1592815094.33.0.264745776024.issue41073@roundup.psfhosted.org>
Message-ID: <1594217379.37.0.429815362965.issue41073@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +20543
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41073>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:25:35 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 14:25:35 +0000
Subject: [issue41241] Unnecessary Type casting in 'if condition'
Message-ID: <1594218335.75.0.478641917124.issue41241@roundup.psfhosted.org>


New submission from Wansoo Kim <rladhkstn8 at gmail.com>:

Hello!

When using 'if syntax', casting condition to bool type is unnecessary. Rather, it only occurs overhead.

https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/asyncio/futures.py#L118

If you look at the link above, the `val` has been cast to bool type. This works well without bool casting.

This issue is my first issue. So if you have a problem, please tell me!

Thanks You!

----------
components: asyncio
messages: 373309
nosy: asvetlov, ys19991, yselivanov
priority: normal
severity: normal
status: open
title: Unnecessary Type casting in 'if condition'
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41241>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:32:58 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 14:32:58 +0000
Subject: [issue41241] Unnecessary Type casting in 'if condition'
In-Reply-To: <1594218335.75.0.478641917124.issue41241@roundup.psfhosted.org>
Message-ID: <1594218778.31.0.931398993901.issue41241@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
pull_requests: +20544
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21396

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41241>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:49:19 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 14:49:19 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
Message-ID: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>


New submission from Wansoo Kim <rladhkstn8 at gmail.com>:

Hello

I think it's better to use += than list.join() when concating strings.

This is more intuitive than other methods.

Also, I personally think it is not good for one variable to change to another type during runtime.

https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/asyncio/base_events.py#L826

If you look at the link above, `msg` was a list type at first, in the end 
 become a str type.

----------
components: asyncio
messages: 373310
nosy: asvetlov, ys19991, yselivanov
priority: normal
severity: normal
status: open
title: When concating strings, I think it is better to use += than join the list
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:54:44 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 14:54:44 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
In-Reply-To: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>
Message-ID: <1594220084.48.0.863573122879.issue41242@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
pull_requests: +20545
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21397

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:59:48 2020
From: report at bugs.python.org (mike bayer)
Date: Wed, 08 Jul 2020 14:59:48 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1594220388.38.0.59654838831.issue22239@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

I tested "cancellation", shutting down the DB connection mid query.  Because the greenlet is only in the middle and not at the endpoints, it propagates the exception and there does not seem to be anything different except for the greenlet sequence in the middle, which is also clear:

https://gist.github.com/zzzeek/9e0d78eff14b3bbd5cf12fed8b02bce6

the first comment on the gist has the stack trace produced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:04:38 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 08 Jul 2020 15:04:38 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
In-Reply-To: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>
Message-ID: <1594220678.89.0.216196884246.issue41242@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Wansoo, using += instead of str.join() is less performant. Concatenating n strings with + will create and allocate n new strings will str.join() will carefully look ahead and allocate the correct amount of memory and do all concatenation at one:


?  ~ python3 -m timeit -s 's = ""' 'for i in range(1_000_000): s += "foo\n"'
5 loops, best of 5: 107 msec per loop
?  ~ python3 -m timeit -s 'l = ["foo"]*1_000_000' '"\n".join(l)'
20 loops, best of 5: 9.96 msec per loop


It's a common idiom that you will meet a lot in Python.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:38:52 2020
From: report at bugs.python.org (Deon)
Date: Wed, 08 Jul 2020 15:38:52 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594222732.38.0.306732532432.issue33840@roundup.psfhosted.org>


Deon <goldgold098123 at gmail.com> added the comment:

hi

----------
nosy: +Deon257

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:41:19 2020
From: report at bugs.python.org (Deon)
Date: Wed, 08 Jul 2020 15:41:19 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594222879.15.0.145128822281.issue33840@roundup.psfhosted.org>


Deon <goldgold098123 at gmail.com> added the comment:

Download FIFA 14 apk
https://apkgreat.com/fifa-14-apk/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:45:02 2020
From: report at bugs.python.org (Deon)
Date: Wed, 08 Jul 2020 15:45:02 +0000
Subject: [issue41243] Android Game
Message-ID: <1594223102.88.0.458247505326.issue41243@roundup.psfhosted.org>


New submission from Deon <goldgold098123 at gmail.com>:

Download FIFA 14 apk

https://apkgreat.com/fifa-14-apk/

----------
components: Interpreter Core
messages: 373315
nosy: Deon257
priority: normal
severity: normal
status: open
title: Android Game
type: security
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41243>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:54:38 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jul 2020 15:54:38 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594223678.23.0.364955563888.issue33840@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373313

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:54:46 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 08 Jul 2020 15:54:46 +0000
Subject: [issue41243] SPAM
In-Reply-To: <1594223102.88.0.458247505326.issue41243@roundup.psfhosted.org>
Message-ID: <1594223686.17.0.619390374267.issue41243@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Android Game -> SPAM
type: security -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41243>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:54:51 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jul 2020 15:54:51 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594223691.05.0.919991493111.issue33840@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373314

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:29:48 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 08 Jul 2020 16:29:48 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
In-Reply-To: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>
Message-ID: <1594225788.96.0.465475419892.issue41242@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:29:32 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 08 Jul 2020 16:29:32 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
In-Reply-To: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>
Message-ID: <1594225772.01.0.557877040819.issue41242@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Remi is correct.
Closing the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:33:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 08 Jul 2020 16:33:28 +0000
Subject: [issue41243] SPAM
Message-ID: <1594226008.95.0.994988807695.issue41243@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373315

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41243>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:33:41 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 08 Jul 2020 16:33:41 +0000
Subject: [issue41243] SPAM
Message-ID: <1594226021.69.0.229068019269.issue41243@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components:  -Interpreter Core
nosy:  -Deon257
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41243>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:56:39 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 16:56:39 +0000
Subject: [issue41244] Change to use str.join() instead of += when
 concatenating string
Message-ID: <1594227399.77.0.946194436689.issue41244@roundup.psfhosted.org>


New submission from Wansoo Kim <rladhkstn8 at gmail.com>:

https://bugs.python.org/issue41242

According to BPO-41242, it is better to use join than += when concatenating multiple strings.

https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/asyncio/queues.py#L82

However, the link above uses += in the same pattern. I think we'd better change this to `str.join()`

----------
components: asyncio
messages: 373317
nosy: asvetlov, ys19991, yselivanov
priority: normal
severity: normal
status: open
title: Change to use str.join() instead of += when concatenating string
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41244>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:57:06 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 16:57:06 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594227426.87.0.344199321255.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

I'm reopening this as the original SEGV didn't go away in 3.9 beta 4. It looks like debug build caught an assertion and prevented the SEGV from triggering.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:01:28 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 17:01:28 +0000
Subject: [issue41244] Change to use str.join() instead of += when
 concatenating string
In-Reply-To: <1594227399.77.0.946194436689.issue41244@roundup.psfhosted.org>
Message-ID: <1594227688.88.0.555570731943.issue41244@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
pull_requests: +20546
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21398

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41244>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:03:48 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 08 Jul 2020 17:03:48 +0000
Subject: [issue41244] Change to use str.join() instead of += when
 concatenating string
In-Reply-To: <1594227399.77.0.946194436689.issue41244@roundup.psfhosted.org>
Message-ID: <1594227828.27.0.507485590768.issue41244@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

That is not performance-critical code, and in that case it is clearer to use `+=` than str.join.

Closing the issue; Andrew or Yury can of course reopen it if they disagree with my assessment.

----------
nosy: +zach.ware
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41244>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:05:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jul 2020 17:05:41 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
In-Reply-To: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>
Message-ID: <1594227941.65.0.381492763853.issue41242@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In this particular case the number of concatenations is limited, the resulting string is usually short, and the code is not performance critical (it is the __repr__ implementation). So there is no significant advantage of one way over other, and no way is obviously wrong. In such cases the status quo wins.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:12:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jul 2020 17:12:30 +0000
Subject: [issue41244] Change to use str.join() instead of += when
 concatenating string
In-Reply-To: <1594227399.77.0.946194436689.issue41244@roundup.psfhosted.org>
Message-ID: <1594228350.85.0.619093850083.issue41244@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Changes in bpo-41242 were rejected not because the new code is worse, but because it is not obviously and significantly better that the existing code. Here status quo wins for the same reasons. This rule saves us from endless rewriting the code and allows to focus on important things.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41244>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:19:11 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Wed, 08 Jul 2020 17:19:11 +0000
Subject: [issue41242] When concating strings,
 I think it is better to use += than join the list
In-Reply-To: <1594219759.44.0.547271428934.issue41242@roundup.psfhosted.org>
Message-ID: <1594228751.79.0.892094896912.issue41242@roundup.psfhosted.org>


Wansoo Kim <rladhkstn8 at gmail.com> added the comment:

Well... to be honest, I'm a little confused. bpo-41244 and this issue are completely opposite. I'm not used to Python community yet because it hasn't been long since I joined it.

You're saying that if a particular method is not dramatically good, we prefer to keep the existing one as it is, right?

Your comment was very helpful to me. Maybe I can learn one by one like this.

Thank you very much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41242>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:19:22 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2020 17:19:22 +0000
Subject: [issue41245] cmath module documentation is misleading on branch cuts
Message-ID: <1594228762.89.0.0337466076831.issue41245@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The documentation for the cmath module is misleading on the behaviour near branch cuts. For example, the documentation for cmath.acos says:

   Return the arc cosine of x. There are two branch cuts: One
   extends right from 1 along the real axis to ?, continuous
   from below. The other extends left from -1 along the real
   axis to -?, continuous from above.

That "continuous from below" and "continuous from above" language is misleading; in fact what happens on the vast majority of systems (those for which the floating-point format used is IEEE 754 binary64), if the imaginary part of x is zero, the sign of x is used to determine which side of the branch cut x lies.

----------
messages: 373323
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: cmath module documentation is misleading on branch cuts

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41245>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:20:08 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 17:20:08 +0000
Subject: [issue41246] IOCP Proactor same socket overlapped callbacks
Message-ID: <1594228808.35.0.788748619653.issue41246@roundup.psfhosted.org>


New submission from Tony <tony.solomonik at gmail.com>:

In IocpProactor I saw that the callbacks to the functions recv, recv_into, recvfrom, sendto, send and sendfile all give the same callback function for when the overlapped operation is done.

I just wanted cleaner code so I made a static function inside the class that I give to each of these functions as the overlapped callbacks.

----------
messages: 373324
nosy: tontinton
priority: normal
severity: normal
status: open
title: IOCP Proactor same socket overlapped callbacks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41246>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:20:25 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2020 17:20:25 +0000
Subject: [issue41245] cmath module documentation is misleading on branch cuts
In-Reply-To: <1594228762.89.0.0337466076831.issue41245@roundup.psfhosted.org>
Message-ID: <1594228825.85.0.672682066668.issue41245@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> the sign of x is used [...]

Correction: That should say "the sign of the imaginary part of x is used [...]"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41245>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:23:08 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2020 17:23:08 +0000
Subject: [issue41245] cmath module documentation is misleading on branch cuts
In-Reply-To: <1594228762.89.0.0337466076831.issue41245@roundup.psfhosted.org>
Message-ID: <1594228988.23.0.041555918254.issue41245@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41245>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:23:24 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 17:23:24 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594229004.54.0.74795012042.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

Confirmed not fixed.

Taken with 3.9 branch as of today.

(pyb-3.9-dev-d) [arcivanov at ai-karellen-lap pybuilder]$ abrt gdb 1f24453
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.
Reading symbols from /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python...
[New LWP 144565]
warning: Unexpected size of section `.reg-xstate/144565' in core file.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/144565' in core file.
#0  0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
128         return ob->ob_type == type;
>From                To                  Syms Read   Shared Object Library
0x00007fcbed8db050  0x00007fcbed8efd69  Yes (*)     /lib64/libcrypt.so.2
0x00007fcbed8beaf0  0x00007fcbed8cdb95  Yes (*)     /lib64/libpthread.so.0
0x00007fcbed8b2270  0x00007fcbed8b31c9  Yes (*)     /lib64/libdl.so.2
0x00007fcbed8ac3f0  0x00007fcbed8acdb0  Yes (*)     /lib64/libutil.so.1
0x00007fcbed7743d0  0x00007fcbed80f078  Yes (*)     /lib64/libm.so.6
0x00007fcbed5c0670  0x00007fcbed70e80f  Yes (*)     /lib64/libc.so.6
0x00007fcbed94f110  0x00007fcbed96f574  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007fcbed91a0f0  0x00007fcbed91bc18  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_heapq.cpython-39d-x86_64-linux-gnu.so
0x00007fcbed93c3d0  0x00007fcbed940cfc  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/zlib.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe00cc5f0  0x00007fcbe00d9bd8  Yes (*)     /lib64/libz.so.1
0x00007fcbed9342f0  0x00007fcbed935f82  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_bz2.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe0078570  0x00007fcbe0084996  Yes (*)     /lib64/libbz2.so.1
0x00007fcbed9294a0  0x00007fcbed92cba6  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_lzma.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe004f9f0  0x00007fcbe0067076  Yes (*)     /lib64/liblzma.so.5
0x00007fcbe0115280  0x00007fcbe01160b3  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/grp.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe0104590  0x00007fcbe010bc77  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/math.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe00fb150  0x00007fcbe00fc200  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_bisect.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe00f52f0  0x00007fcbe00f6a1e  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_random.cpython-39d-x86_64-linux-gnu.so
0x00007fcbe00ea190  0x00007fcbe00efad0  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_sha512.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfef05a0  0x00007fcbdff012c9  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_datetime.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfedd420  0x00007fcbdfee607e  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_json.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfed53f0  0x00007fcbdfed734f  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_posixsubprocess.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfeca400  0x00007fcbdfecd9b2  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/select.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfe3c530  0x00007fcbdfe41ed1  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_struct.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfe198e0  0x00007fcbdfe2d938  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_pickle.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfdbc820  0x00007fcbdfdc858e  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_socket.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfda9560  0x00007fcbdfdb0c78  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/array.cpython-39d-x86_64-linux-gnu.so
0x00007fcbed9220e0  0x00007fcbed922547  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_opcode.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfbcb270  0x00007fcbdfbcfbbf  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/binascii.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdfb8b4f0  0x00007fcbdfbb92b1  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/pyexpat.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdf7786a0  0x00007fcbdf77e878  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_hashlib.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdf6c68d0  0x00007fcbdf71316a  Yes (*)     /lib64/libssl.so.1.1
0x00007fcbdf435000  0x00007fcbdf5df6c0  Yes (*)     /lib64/libcrypto.so.1.1
0x00007fcbdf760270  0x00007fcbdf76fec6  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_blake2.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdf356280  0x00007fcbdf3637c4  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_ssl.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdf1e2a80  0x00007fcbdf1f8636  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_ctypes.cpython-39d-x86_64-linux-gnu.so
0x00007fcbdf7552c0  0x00007fcbdf759d4c  Yes (*)     /lib64/libffi.so.6
0x00007fcbe01de2b0  0x00007fcbe01df189  Yes         /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/lib/python3.9/lib-dynload/_multiprocessing.cpython-39d-x86_64-linux-gnu.so
(*): Shared library is missing debugging information.
#0  0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
#1  0x0000000000623487 in _PyType_CheckExact (op=0x0) at ./Include/object.h:641
#2  0x0000000000628d85 in object_recursive_isinstance (tstate=0xeca210, inst=0x14c7f40, cls=0x0) at Objects/abstract.c:2495
#3  0x0000000000628fdc in PyObject_IsInstance (inst=0x14c7f40, cls=0x0) at Objects/abstract.c:2551
#4  0x0000000000682420 in PyAST_Check (obj=0x14c7f40) at Python/Python-ast.c:10356
#5  0x000000000069c754 in builtin_compile_impl (module=0x7fcbe0546a10, source=0x14c7f40, filename=0x7fcbdf183940, mode=0x7fcbe05472f0 "eval", flags=1024, dont_inherit=0, optimize=-1, feature_version=-1) at Python/bltinmodule.c:784
#6  0x000000000069aa72 in builtin_compile (module=0x7fcbe0546a10, args=0x7ffe56fe69f0, nargs=4, kwnames=0x7fcbdf0e55a0) at Python/clinic/bltinmodule.c.h:274
#7  0x0000000000655297 in cfunction_vectorcall_FASTCALL_KEYWORDS (func=0x7fcbe0548050, args=0x1351330, nargsf=9223372036854775812, kwnames=0x7fcbdf0e55a0) at Objects/methodobject.c:440
#8  0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe0548050, args=0x1351330, nargsf=9223372036854775812, kwnames=0x7fcbdf0e55a0) at ./Include/cpython/abstract.h:118
#9  0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe0548050, args=0x1351330, nargsf=9223372036854775812, kwnames=0x7fcbdf0e55a0) at ./Include/cpython/abstract.h:127
#10 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56fe6c58, oparg=5, kwnames=0x7fcbdf0e55a0) at Python/ceval.c:5044
#11 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x1351180, throwflag=0) at Python/ceval.c:3507
#12 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x1351180, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#13 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbdf111c70, globals=0x7fcbdf1836b0, locals=0x0, args=0x7fcbdec303c8, argcount=1, kwnames=0x7fcbdf0e5b08, kwargs=0x7fcbdec303d0, kwcount=1, kwstep=1, defs=0x7fcbdf0e90b8, defcount=2, 
    kwdefs=0x7fcbdefcd470, closure=0x0, name=0x7fcbe032b450, qualname=0x7fcbe032b450) at Python/ceval.c:4299
#14 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbdefb1230, stack=0x7fcbdec303c8, nargsf=9223372036854775809, kwnames=0x7fcbdf0e5af0) at Objects/call.c:395
#15 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdefb1230, args=0x7fcbdec303c8, nargsf=9223372036854775809, kwnames=0x7fcbdf0e5af0) at ./Include/cpython/abstract.h:118
#16 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdefb1230, args=0x7fcbdec303c8, nargsf=9223372036854775809, kwnames=0x7fcbdf0e5af0) at ./Include/cpython/abstract.h:127
#17 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56fe8478, oparg=2, kwnames=0x7fcbdf0e5af0) at Python/ceval.c:5044
#18 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdec30230, throwflag=0) at Python/ceval.c:3507
#19 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdec30230, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#20 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbdefb5930, globals=0x7fcbdf1836b0, locals=0x0, args=0x7fcbdeca69b8, argcount=1, kwnames=0x0, kwargs=0x7fcbdeca69c0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7fcbdfe0b400, qualname=0x7fcbdfe0b400) at Python/ceval.c:4299
#21 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbdefb1f50, stack=0x7fcbdeca69b8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:395
#22 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdefb1f50, args=0x7fcbdeca69b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#23 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdefb1f50, args=0x7fcbdeca69b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#24 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56fe9cb8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#25 0x00000000005193a1 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdeca6810, throwflag=0) at Python/ceval.c:3459
#26 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdeca6810, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#27 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbdef535f0, args=0x7fcbdf2579b8, nargs=1, globals=0x7fcbdef4f410) at Objects/call.c:329
#28 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbdec9baf0, stack=0x7fcbdf2579b0, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#29 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdec9baf0, args=0x7fcbdf2579b0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#30 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdec9baf0, args=0x7fcbdf2579b0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#31 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56feb368, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#32 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdf257810, throwflag=0) at Python/ceval.c:3476
#33 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdf257810, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#34 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbdef37ee0, globals=0x7fcbdef841d0, locals=0x0, args=0x7ffe56feca70, argcount=3, kwnames=0x0, kwargs=0x7ffe56feca88, kwcount=0, kwstep=1, defs=0x7fcbdef48158, defcount=1, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe0564460, qualname=0x7fcbdef3d7c0) at Python/ceval.c:4299
#35 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbdec22870, stack=0x7ffe56feca70, nargsf=3, kwnames=0x0) at Objects/call.c:395
#36 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0xeca210, callable=0x7fcbdec22870, args=0x7ffe56feca70, nargsf=3, kwargs=0x0) at Objects/call.c:118
#37 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0xeca210, callable=0x7fcbdec22870, obj=0x7fcbdec94500, args=0x7fcbdf0a5c30, kwargs=0x0) at Objects/call.c:488
#38 0x00000000004a2aee in slot_tp_init (self=0x7fcbdec94500, args=0x7fcbdf0a5c30, kwds=0x0) at Objects/typeobject.c:6927
#39 0x0000000000492464 in type_call (type=0x14c09e0, args=0x7fcbdf0a5c30, kwds=0x0) at Objects/typeobject.c:1026
#40 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0xeca210, callable=0x14c09e0, args=0x7fcbdec2d748, nargs=2, keywords=0x0) at Objects/call.c:191
#41 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x14c09e0, args=0x7fcbdec2d748, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:116
#42 0x0000000000509a90 in PyObject_Vectorcall (callable=0x14c09e0, args=0x7fcbdec2d748, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#43 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56fecd78, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#44 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdec2d5c0, throwflag=0) at Python/ceval.c:3490
#45 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdec2d5c0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#46 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbdefadd40, args=0x12cceb0, nargs=1, globals=0x7fcbdf2a6e90) at Objects/call.c:329
#47 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbdec2b370, stack=0x12ccea8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#48 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdec2b370, args=0x12ccea8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#49 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdec2b370, args=0x12ccea8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#50 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56fee428, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#51 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x12ccce0, throwflag=0) at Python/ceval.c:3490
#52 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x12ccce0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#53 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbdef7a930, globals=0x7fcbdf2a6e90, locals=0x0, args=0x7fcbdf153c68, argcount=3, kwnames=0x0, kwargs=0x7fcbdf153c80, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe042b630, qualname=0x7fcbe042b630) at Python/ceval.c:4299
#54 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbdec2bcd0, stack=0x7fcbdf153c68, nargsf=3, kwnames=0x0) at Objects/call.c:395
#55 0x0000000000430faa in PyVectorcall_Call (callable=0x7fcbdec2bcd0, tuple=0x7fcbdf153c50, kwargs=0x0) at Objects/call.c:230
#56 0x0000000000431155 in _PyObject_Call (tstate=0xeca210, callable=0x7fcbdec2bcd0, args=0x7fcbdf153c50, kwargs=0x0) at Objects/call.c:265
#57 0x000000000043123c in PyObject_Call (callable=0x7fcbdec2bcd0, args=0x7fcbdf153c50, kwargs=0x0) at Objects/call.c:292
#58 0x000000000051ef87 in do_call_core (tstate=0xeca210, func=0x7fcbdec2bcd0, callargs=0x7fcbdf153c50, kwdict=0x0) at Python/ceval.c:5092
#59 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x12f3df0, throwflag=0) at Python/ceval.c:3552
#60 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0x12f3df0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#61 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbdf1111e0, args=0x130c4a0, nargs=0, globals=0x7fcbdf0a1ad0) at Objects/call.c:329
#62 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbdfe992d0, stack=0x130c4a0, nargsf=9223372036854775808, kwnames=0x0) at Objects/call.c:366
#63 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdfe992d0, args=0x130c4a0, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:118
#64 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdfe992d0, args=0x130c4a0, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#65 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ff1338, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#66 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x130c330, throwflag=0) at Python/ceval.c:3490
#67 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x130c330, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#68 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbdf111110, globals=0x7fcbdfe92530, locals=0x7fcbdfe92530, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4299
#69 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=0x7fcbdf111110, globals=0x7fcbdfe92530, locals=0x7fcbdfe92530, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#70 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=0x7fcbdf111110, globals=0x7fcbdfe92530, locals=0x7fcbdfe92530, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#71 0x000000000050bbc0 in PyEval_EvalCode (co=0x7fcbdf111110, globals=0x7fcbdfe92530, locals=0x7fcbdfe92530) at Python/ceval.c:809
#72 0x000000000069ce37 in builtin_exec_impl (module=0x7fcbe0546a10, source=0x7fcbdf111110, globals=0x7fcbdfe92530, locals=0x7fcbdfe92530) at Python/bltinmodule.c:1035
#73 0x000000000069ac76 in builtin_exec (module=0x7fcbe0546a10, args=0x12b5070, nargs=2) at Python/clinic/bltinmodule.c.h:396
#74 0x00000000006551f4 in cfunction_vectorcall_FASTCALL (func=0x7fcbe0548230, args=0x12b5070, nargsf=9223372036854775810, kwnames=0x0) at Objects/methodobject.c:424
#75 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe0548230, args=0x12b5070, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#76 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe0548230, args=0x12b5070, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#77 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ff2ce8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#78 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x12b4eb0, throwflag=0) at Python/ceval.c:3490
#79 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x12b4eb0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#80 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe01aa110, globals=0x7fcbe02977d0, locals=0x0, args=0x1368428, argcount=7, kwnames=0x0, kwargs=0x1368460, kwcount=0, kwstep=1, defs=0x7fcbe01be848, defcount=5, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe01bda60, qualname=0x7fcbe01bda60) at Python/ceval.c:4299
#81 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe01bc550, stack=0x1368428, nargsf=9223372036854775815, kwnames=0x0) at Objects/call.c:395
#82 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe01bc550, args=0x1368428, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:118
#83 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe01bc550, args=0x1368428, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:127
#84 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ff4508, oparg=7, kwnames=0x0) at Python/ceval.c:5044
#85 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x1368260, throwflag=0) at Python/ceval.c:3490
#86 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x1368260, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#87 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe01aa520, globals=0x7fcbe02977d0, locals=0x0, args=0x10ea740, argcount=3, kwnames=0x7fcbe0261658, kwargs=0x10ea758, kwcount=2, kwstep=1, defs=0x7fcbe01be8b8, defcount=5, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe01bdb80, qualname=0x7fcbe01bdb80) at Python/ceval.c:4299
#88 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe0130c30, stack=0x10ea740, nargsf=9223372036854775811, kwnames=0x7fcbe0261640) at Objects/call.c:395
#89 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe0130c30, args=0x10ea740, nargsf=9223372036854775811, kwnames=0x7fcbe0261640) at ./Include/cpython/abstract.h:118
#90 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe0130c30, args=0x10ea740, nargsf=9223372036854775811, kwnames=0x7fcbe0261640) at ./Include/cpython/abstract.h:127
#91 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ff5d18, oparg=5, kwnames=0x7fcbe0261640) at Python/ceval.c:5044
#92 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x10ea570, throwflag=0) at Python/ceval.c:3507
#93 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x10ea570, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#94 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe01b2ba0, globals=0x7fcbe02977d0, locals=0x0, args=0x135d578, argcount=1, kwnames=0x7fcbe043a9c8, kwargs=0x135d580, kwcount=1, kwstep=1, defs=0x7fcbe02615b8, defcount=2, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe04159a0, qualname=0x7fcbe04159a0) at Python/ceval.c:4299
#95 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe0137050, stack=0x135d578, nargsf=9223372036854775809, kwnames=0x7fcbe043a9b0) at Objects/call.c:395
#96 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe0137050, args=0x135d578, nargsf=9223372036854775809, kwnames=0x7fcbe043a9b0) at ./Include/cpython/abstract.h:118
#97 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe0137050, args=0x135d578, nargsf=9223372036854775809, kwnames=0x7fcbe043a9b0) at ./Include/cpython/abstract.h:127
#98 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ff7538, oparg=2, kwnames=0x7fcbe043a9b0) at Python/ceval.c:5044
#99 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x135d3d0, throwflag=0) at Python/ceval.c:3507
#100 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x135d3d0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#101 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe0296110, globals=0x7fcbe04152f0, locals=0x0, args=0x101c418, argcount=4, kwnames=0x0, kwargs=0x101c438, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x7fcbe0430040, 
    qualname=0x7fcbe0295820) at Python/ceval.c:4299
#102 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe00307d0, stack=0x101c418, nargsf=9223372036854775812, kwnames=0x0) at Objects/call.c:395
#103 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe00307d0, args=0x101c418, nargsf=9223372036854775812, kwnames=0x0) at ./Include/cpython/abstract.h:118
#104 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe00307d0, args=0x101c418, nargsf=9223372036854775812, kwnames=0x0) at ./Include/cpython/abstract.h:127
#105 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ff8d78, oparg=4, kwnames=0x0) at Python/ceval.c:5044
#106 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x101c2a0, throwflag=0) at Python/ceval.c:3476
#107 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0x101c2a0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#108 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbe0425d40, args=0xfec1b0, nargs=1, globals=0x7fcbe0495a10) at Objects/call.c:329
#109 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbe00309b0, stack=0xfec1a8, nargsf=1, kwnames=0x0) at Objects/call.c:366
#110 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe00309b0, args=0xfec1a8, nargsf=1, kwnames=0x0) at ./Include/cpython/abstract.h:118
#111 0x000000000063c0e6 in method_vectorcall (method=0x7fcbdffe1650, args=0xfec1b0, nargsf=9223372036854775808, kwnames=0x0) at Objects/classobject.c:53
#112 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdffe1650, args=0xfec1b0, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:118
#113 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdffe1650, args=0xfec1b0, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#114 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ffa528, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#115 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0xfec030, throwflag=0) at Python/ceval.c:3490
#116 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0xfec030, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#117 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbe0311a00, args=0x1013520, nargs=2, globals=0x7fcbe0415650) at Objects/call.c:329
#118 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbe0269910, stack=0x1013510, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#119 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe0269910, args=0x1013510, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#120 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe0269910, args=0x1013510, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#121 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ffbbe8, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#122 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x1013330, throwflag=0) at Python/ceval.c:3476
#123 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x1013330, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#124 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe0311d40, globals=0x7fcbe0415650, locals=0x0, args=0x7ffe56ffd2d0, argcount=2, kwnames=0x0, kwargs=0x7ffe56ffd2e0, kwcount=0, kwstep=1, defs=0x7fcbe031f428, defcount=1, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe053a590, qualname=0x7fcbe0314ca0) at Python/ceval.c:4299
#125 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe0269af0, stack=0x7ffe56ffd2d0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#126 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe0269af0, args=0x7ffe56ffd2d0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#127 0x000000000063c24f in method_vectorcall (method=0x7fcbdffe1470, args=0x7fcbe0039568, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#128 0x0000000000430faa in PyVectorcall_Call (callable=0x7fcbdffe1470, tuple=0x7fcbe0039550, kwargs=0x7fcbdffe1410) at Objects/call.c:230
#129 0x0000000000431155 in _PyObject_Call (tstate=0xeca210, callable=0x7fcbdffe1470, args=0x7fcbe0039550, kwargs=0x7fcbdffe1410) at Objects/call.c:265
#130 0x000000000043123c in PyObject_Call (callable=0x7fcbdffe1470, args=0x7fcbe0039550, kwargs=0x7fcbdffe1410) at Objects/call.c:292
#131 0x000000000051ef87 in do_call_core (tstate=0xeca210, func=0x7fcbdffe1470, callargs=0x7fcbe0039550, kwdict=0x7fcbdffe1410) at Python/ceval.c:5092
#132 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdffe5050, throwflag=0) at Python/ceval.c:3552
#133 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdffe5050, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#134 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe0316040, globals=0x7fcbe0415650, locals=0x0, args=0x7ffe56ffec60, argcount=2, kwnames=0x0, kwargs=0x7ffe56ffec70, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe05642e0, qualname=0x7fcbe0314e80) at Python/ceval.c:4299
#135 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe0269cd0, stack=0x7ffe56ffec60, nargsf=2, kwnames=0x0) at Objects/call.c:395
#136 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0xeca210, callable=0x7fcbe0269cd0, args=0x7ffe56ffec60, nargsf=2, kwargs=0x0) at Objects/call.c:118
#137 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0xeca210, callable=0x7fcbe0269cd0, obj=0x7fcbdffe0730, args=0x7fcbe00323c0, kwargs=0x0) at Objects/call.c:488
#138 0x00000000004a243a in slot_tp_call (self=0x7fcbdffe0730, args=0x7fcbe00323c0, kwds=0x0) at Objects/typeobject.c:6687
#139 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0xeca210, callable=0x7fcbdffe0730, args=0x7fcbdffe49b8, nargs=1, keywords=0x0) at Objects/call.c:191
#140 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdffe0730, args=0x7fcbdffe49b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#141 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdffe0730, args=0x7fcbdffe49b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#142 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe56ffef18, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#143 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdffe4810, throwflag=0) at Python/ceval.c:3490
#144 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdffe4810, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#145 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe02d21e0, globals=0x7fcbe03a70b0, locals=0x0, args=0x7ffe57000610, argcount=2, kwnames=0x0, kwargs=0x7ffe57000620, kwcount=0, kwstep=1, defs=0x7fcbe02700b8, defcount=1, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe053a590, qualname=0x7fcbe026ee20) at Python/ceval.c:4299
#146 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe02724b0, stack=0x7ffe57000610, nargsf=2, kwnames=0x0) at Objects/call.c:395
#147 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe02724b0, args=0x7ffe57000610, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#148 0x000000000063c24f in method_vectorcall (method=0x7fcbdffe13b0, args=0x7fcbe0032298, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#149 0x0000000000430faa in PyVectorcall_Call (callable=0x7fcbdffe13b0, tuple=0x7fcbe0032280, kwargs=0x7fcbdffe1350) at Objects/call.c:230
#150 0x0000000000431155 in _PyObject_Call (tstate=0xeca210, callable=0x7fcbdffe13b0, args=0x7fcbe0032280, kwargs=0x7fcbdffe1350) at Objects/call.c:265
#151 0x000000000043123c in PyObject_Call (callable=0x7fcbdffe13b0, args=0x7fcbe0032280, kwargs=0x7fcbdffe1350) at Objects/call.c:292
#152 0x000000000051ef87 in do_call_core (tstate=0xeca210, func=0x7fcbdffe13b0, callargs=0x7fcbe0032280, kwdict=0x7fcbdffe1350) at Python/ceval.c:5092
#153 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbe002ab30, throwflag=0) at Python/ceval.c:3552
#154 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbe002ab30, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#155 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe02cc930, globals=0x7fcbe03a70b0, locals=0x0, args=0x7ffe57001fa0, argcount=2, kwnames=0x0, kwargs=0x7ffe57001fb0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe05642e0, qualname=0x7fcbe026eac0) at Python/ceval.c:4299
#156 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe0272370, stack=0x7ffe57001fa0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#157 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0xeca210, callable=0x7fcbe0272370, args=0x7ffe57001fa0, nargsf=2, kwargs=0x0) at Objects/call.c:118
#158 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0xeca210, callable=0x7fcbe0272370, obj=0x7fcbdffe0640, args=0x7fcbe0023230, kwargs=0x0) at Objects/call.c:488
#159 0x00000000004a243a in slot_tp_call (self=0x7fcbdffe0640, args=0x7fcbe0023230, kwds=0x0) at Objects/typeobject.c:6687
#160 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0xeca210, callable=0x7fcbdffe0640, args=0x7fcbdffe47c8, nargs=1, keywords=0x0) at Objects/call.c:191
#161 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdffe0640, args=0x7fcbdffe47c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#162 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdffe0640, args=0x7fcbdffe47c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#163 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe57002258, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#164 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdffe4620, throwflag=0) at Python/ceval.c:3490
#165 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdffe4620, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#166 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe02d21e0, globals=0x7fcbe03a70b0, locals=0x0, args=0x7ffe57003950, argcount=2, kwnames=0x0, kwargs=0x7ffe57003960, kwcount=0, kwstep=1, defs=0x7fcbe02700b8, defcount=1, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe053a590, qualname=0x7fcbe026ee20) at Python/ceval.c:4299
#167 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe02724b0, stack=0x7ffe57003950, nargsf=2, kwnames=0x0) at Objects/call.c:395
#168 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe02724b0, args=0x7ffe57003950, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#169 0x000000000063c24f in method_vectorcall (method=0x7fcbdffe12f0, args=0x7fcbe0025d38, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#170 0x0000000000430faa in PyVectorcall_Call (callable=0x7fcbdffe12f0, tuple=0x7fcbe0025d20, kwargs=0x7fcbdffe1290) at Objects/call.c:230
#171 0x0000000000431155 in _PyObject_Call (tstate=0xeca210, callable=0x7fcbdffe12f0, args=0x7fcbe0025d20, kwargs=0x7fcbdffe1290) at Objects/call.c:265
#172 0x000000000043123c in PyObject_Call (callable=0x7fcbdffe12f0, args=0x7fcbe0025d20, kwargs=0x7fcbdffe1290) at Objects/call.c:292
#173 0x000000000051ef87 in do_call_core (tstate=0xeca210, func=0x7fcbdffe12f0, callargs=0x7fcbe0025d20, kwdict=0x7fcbdffe1290) at Python/ceval.c:5092
#174 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbe002a960, throwflag=0) at Python/ceval.c:3552
#175 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbe002a960, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#176 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe02cc930, globals=0x7fcbe03a70b0, locals=0x0, args=0x7ffe570052e0, argcount=2, kwnames=0x0, kwargs=0x7ffe570052f0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, 
    name=0x7fcbe05642e0, qualname=0x7fcbe026eac0) at Python/ceval.c:4299
#177 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe0272370, stack=0x7ffe570052e0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#178 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0xeca210, callable=0x7fcbe0272370, args=0x7ffe570052e0, nargsf=2, kwargs=0x0) at Objects/call.c:118
#179 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0xeca210, callable=0x7fcbe0272370, obj=0x7fcbdffd8550, args=0x7fcbe00c5640, kwargs=0x0) at Objects/call.c:488
#180 0x00000000004a243a in slot_tp_call (self=0x7fcbdffd8550, args=0x7fcbe00c5640, kwds=0x0) at Objects/typeobject.c:6687
#181 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0xeca210, callable=0x7fcbdffd8550, args=0x100bf28, nargs=1, keywords=0x0) at Objects/call.c:191
#182 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbdffd8550, args=0x100bf28, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#183 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbdffd8550, args=0x100bf28, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#184 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe57005598, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#185 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x100bd30, throwflag=0) at Python/ceval.c:3490
#186 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0x100bd30, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#187 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbe029ee10, args=0x7fcbdffe41e0, nargs=2, globals=0x7fcbe0258ad0) at Objects/call.c:329
#188 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbe01bb9b0, stack=0x7fcbdffe41d0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#189 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe01bb9b0, args=0x7fcbdffe41d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#190 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe01bb9b0, args=0x7fcbdffe41d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#191 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe57006c58, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#192 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x7fcbdffe4050, throwflag=0) at Python/ceval.c:3476
#193 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0xeca210, f=0x7fcbdffe4050, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#194 0x0000000000431372 in function_code_fastcall (tstate=0xeca210, co=0x7fcbe02861e0, args=0x10091c8, nargs=1, globals=0x7fcbe0273170) at Objects/call.c:329
#195 0x00000000004315c0 in _PyFunction_Vectorcall (func=0x7fcbe01bc2d0, stack=0x10091c0, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#196 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0x7fcbe01bc2d0, args=0x10091c0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#197 0x0000000000509a90 in PyObject_Vectorcall (callable=0x7fcbe01bc2d0, args=0x10091c0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#198 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe57008308, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#199 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0x1008fe0, throwflag=0) at Python/ceval.c:3476
#200 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0x1008fe0, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#201 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe027c930, globals=0x7fcbe0273170, locals=0x0, args=0x7ffe57009a10, argcount=1, kwnames=0x0, kwargs=0x7ffe57009a18, kwcount=0, kwstep=1, defs=0x7fcbe01bbba8, defcount=11, kwdefs=0x7fcbe02870b0, 
    closure=0x0, name=0x7fcbe0564460, qualname=0x7fcbe0280c40) at Python/ceval.c:4299
#202 0x0000000000431853 in _PyFunction_Vectorcall (func=0x7fcbe01bbc30, stack=0x7ffe57009a10, nargsf=1, kwnames=0x0) at Objects/call.c:395
#203 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0xeca210, callable=0x7fcbe01bbc30, args=0x7ffe57009a10, nargsf=1, kwargs=0x0) at Objects/call.c:118
#204 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0xeca210, callable=0x7fcbe01bbc30, obj=0x7fcbe0416780, args=0x7fcbe0567050, kwargs=0x0) at Objects/call.c:488
#205 0x00000000004a2aee in slot_tp_init (self=0x7fcbe0416780, args=0x7fcbe0567050, kwds=0x0) at Objects/typeobject.c:6927
#206 0x0000000000492464 in type_call (type=0xfc3f80, args=0x7fcbe0567050, kwds=0x0) at Objects/typeobject.c:1026
#207 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0xeca210, callable=0xfc3f80, args=0xf298e8, nargs=0, keywords=0x0) at Objects/call.c:191
#208 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0xeca210, callable=0xfc3f80, args=0xf298e8, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:116
#209 0x0000000000509a90 in PyObject_Vectorcall (callable=0xfc3f80, args=0xf298e8, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#210 0x000000000051ea52 in call_function (tstate=0xeca210, pp_stack=0x7ffe57009d28, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#211 0x00000000005193a1 in _PyEval_EvalFrameDefault (tstate=0xeca210, f=0xf29770, throwflag=0) at Python/ceval.c:3459
#212 0x0000000000509cde in _PyEval_EvalFrame (tstate=0xeca210, f=0xf29770, throwflag=0) at ./Include/internal/pycore_ceval.h:40
#213 0x000000000051cf4e in _PyEval_EvalCode (tstate=0xeca210, _co=0x7fcbe0428860, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, 
    qualname=0x0) at Python/ceval.c:4299
#214 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=0x7fcbe0428860, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at Python/ceval.c:4331
#215 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=0x7fcbe0428860, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#216 0x000000000050bbc0 in PyEval_EvalCode (co=0x7fcbe0428860, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10) at Python/ceval.c:809
#217 0x000000000056eaf9 in run_eval_code_obj (tstate=0xeca210, co=0x7fcbe0428860, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10) at Python/pythonrun.c:1178
#218 0x000000000056ebe2 in run_mod (mod=0xf48f98, filename=0x7fcbe045b720, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10, flags=0x7ffe5700b728, arena=0x7fcbe042aac0) at Python/pythonrun.c:1199
#219 0x000000000056e971 in PyRun_FileExFlags (fp=0xec7110, filename_str=0x7fcbe0429240 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", start=257, globals=0x7fcbe0495a10, locals=0x7fcbe0495a10, closeit=1, 
    flags=0x7ffe5700b728) at Python/pythonrun.c:1116
#220 0x000000000056d447 in PyRun_SimpleFileExFlags (fp=0xec7110, filename=0x7fcbe0429240 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", closeit=1, flags=0x7ffe5700b728) at Python/pythonrun.c:438
#221 0x000000000056c958 in PyRun_AnyFileExFlags (fp=0xec7110, filename=0x7fcbe0429240 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", closeit=1, flags=0x7ffe5700b728) at Python/pythonrun.c:87
#222 0x000000000041e6e8 in pymain_run_file (config=0xec8990, cf=0x7ffe5700b728) at Modules/main.c:369
#223 0x000000000041ecd8 in pymain_run_python (exitcode=0x7ffe5700b76c) at Modules/main.c:594
#224 0x000000000041edc9 in Py_RunMain () at Modules/main.c:673
#225 0x000000000041ee43 in pymain_main (args=0x7ffe5700b7d0) at Modules/main.c:703
#226 0x000000000041eebd in Py_BytesMain (argc=2, argv=0x7ffe5700b908) at Modules/main.c:727
#227 0x000000000041d786 in main (argc=2, argv=0x7ffe5700b908) at ./Programs/python.c:15
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.8-2.fc32.x86_64 glibc-2.31-2.fc32.x86_64 libffi-3.1-24.fc32.x86_64 libxcrypt-4.4.16-3.fc32.x86_64 openssl-libs-1.1.1g-1.fc32.x86_64 xz-libs-5.2.5-1.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:38:12 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Wed, 08 Jul 2020 17:38:12 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594229892.05.0.625513060315.issue40360@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

I've written up a proposal for adding "whitespace" handling to the ast module:
https://mail.python.org/archives/list/python-ideas at python.org/thread/X2HJ6I6XLIGRZDB27HRHIVQC3RXNZAY4/

I don't think it's a "summer-of-code-sized project", mainly because I already have various bits of code that handle the fiddly byte/str offset conversions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul  8 13:37:58 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 17:37:58 +0000
Subject: [issue41246] IOCP Proactor same socket overlapped callbacks
In-Reply-To: <1594228808.35.0.788748619653.issue41246@roundup.psfhosted.org>
Message-ID: <1594229878.62.0.872091741313.issue41246@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
keywords: +patch
pull_requests: +20547
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21399

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41246>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:41:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jul 2020 18:41:21 +0000
Subject: [issue41245] cmath module documentation is misleading on branch cuts
In-Reply-To: <1594228762.89.0.0337466076831.issue41245@roundup.psfhosted.org>
Message-ID: <1594233681.79.0.0424403730471.issue41245@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for changing the language to match the actual mechanics.


> "the sign of the imaginary part of x is used [...]"

I'm trying to see where this happens.  Is this part of cmath_sqrt?

    if (z.real >= 0.) {
        r.real = s;
        r.imag = copysign(d, z.imag); 
    } else {
        r.real = d;
        r.imag = copysign(s, z.imag);
    }


> "continuous from below" and "continuous from above" 
> language is misleading;

I'm curious, is that language incorrect?  My mental image of a branch cut is a helical graph with the edge cases being continuous from above and below.  Likewise, my mental model for branch cut logic is it resolves multiple possible output values in a way preserves continuity from one side or the other.

In other words, I think about branch cuts in terms of continuity rather than sign preservation.  Is that incorrect?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41245>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:41:45 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jul 2020 18:41:45 +0000
Subject: [issue41172] test_peg_generator C tests fail on Windows ARM
In-Reply-To: <1593532643.61.0.103127847831.issue41172@roundup.psfhosted.org>
Message-ID: <1594233705.73.0.792793242994.issue41172@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20549
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21400

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41172>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:51:22 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2020 18:51:22 +0000
Subject: [issue41245] cmath module documentation is misleading on branch cuts
In-Reply-To: <1594228762.89.0.0337466076831.issue41245@roundup.psfhosted.org>
Message-ID: <1594234282.87.0.273102613267.issue41245@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, that looks like the right part of the sqrt code.

For the acos docstring, "continuous from below" implies that for any complex number z that lies exactly _on_ the branch cut, acos(z) is close to acos(w) for a nearby value w just _below_ the branch cut. But that's demonstrably not true: see the change of sign in the real part below:

>>> acos(complex(2.3, -1e-10))  # value just "below" the branch cut
(4.828045495852677e-11+1.475044781241425j)
>>> acos(complex(2.3, 0.0))  # nearby value exactly _on_ the branch cut
-1.475044781241425j

In effect, for a branch cut along the real axis, the sign of the zero in the imaginary part of the argument allows us to be continuous from both sides at once.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41245>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:52:27 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2020 18:52:27 +0000
Subject: [issue41245] cmath module documentation is misleading on branch cuts
In-Reply-To: <1594228762.89.0.0337466076831.issue41245@roundup.psfhosted.org>
Message-ID: <1594234347.48.0.543637019661.issue41245@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> [...] see the change of sign in the real part below [...]

Grr. Stupid fingers. That should say "imaginary part", not "real part"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41245>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:58:38 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 08 Jul 2020 18:58:38 +0000
Subject: [issue41244] Change to use str.join() instead of += when
 concatenating string
In-Reply-To: <1594227399.77.0.946194436689.issue41244@roundup.psfhosted.org>
Message-ID: <1594234718.32.0.0964195795778.issue41244@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Changes in bpo-41242 were rejected not because the new code is worse, but because it is not obviously and significantly better that the existing code. Here status quo wins for the same reasons. This rule saves us from endless rewriting the code and allows to focus on important things.

+1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41244>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:59:47 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 08 Jul 2020 18:59:47 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594234787.47.0.0169236378131.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Can that be done as a 3rd party wrapper? Then you would be able to support older Python versions, and typed_ast (which can parse older Python grammars with a newer Python that's older than 3.8). Plus it would be much easier to get your code released -- no waiting for core devs to review it or waiting for the next CPython (bugfix or feature) release to get a bug fixed or small feature added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:00:14 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 19:00:14 +0000
Subject: [issue41247] asyncio module better caching for set and
 get_running_loop
Message-ID: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>


New submission from Tony <tony.solomonik at gmail.com>:

There is a cache variable for the running loop holder, but once set_running_loop is called the variable was set to NULL so the next time get_running_loop would have to query a dictionary to receive the running loop holder.

I thought why not always cache the latest set_running_loop?

The only issue I thought of here is in the details of the implementation: I have too little experience in python to know if there could be a context switch to get_running_loop while set_running_loop is running.

If a context switch is possible there then this issue would be way harder to solve, but it is still solvable.

----------
messages: 373333
nosy: tontinton
priority: normal
severity: normal
status: open
title: asyncio module better caching for set and get_running_loop

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:05:48 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Wed, 08 Jul 2020 19:05:48 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594235148.41.0.65528733306.issue40360@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

Yes, I'm thinking of doing this as a wrapper, in such a way that it could be incorporated into Lib/ast.py eventually. (Also, any lib2to3-ish capabilities would probably not be suitable for inclusion in the stdlib, at least not initially ... but I have no plans to work on something to replace lib2to3's fixers.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:06:39 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 19:06:39 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594235199.31.0.0592028032132.issue41247@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
keywords: +patch
pull_requests: +20550
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:06:04 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 19:06:04 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594235164.47.0.628735278603.issue41247@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
title: asyncio module better caching for set and get_running_loop -> asyncio.set_running_loop() cache running loop holder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:17:31 2020
From: report at bugs.python.org (Mischiew Rithe)
Date: Wed, 08 Jul 2020 19:17:31 +0000
Subject: [issue41248] Python manual forced in maximized window
Message-ID: <1594235851.53.0.79291256825.issue41248@roundup.psfhosted.org>


New submission from Mischiew Rithe <mischiew at gmail.com>:

In versions 3.8.1 and 3.8.3-amd64 (only versions tested), on Windows, the "Python 3.8 Manuals" opens in a maximized window.

This is unexpected and undesired, as the user cannot see the other windows, including the one he's developing from (IDE, editor, shell, ...).

The problem seems to come from the shortcut created in the menu, which forces a maximized window. It has to be set to "normal window" instead.

----------
assignee: docs at python
components: Documentation
messages: 373335
nosy: Mischiew Rithe, docs at python
priority: normal
severity: normal
status: open
title: Python manual forced in maximized window
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41248>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:27:39 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 19:27:39 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594236459.14.0.552711677456.issue41247@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 529f42645d38b6b0075f256814dfb3d220ac7d92 by Tony Solomonik in branch 'master':
bpo-41247: asyncio.set_running_loop() cache running loop holder (GH-21401)
https://github.com/python/cpython/commit/529f42645d38b6b0075f256814dfb3d220ac7d92


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:28:04 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 19:28:04 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594236484.88.0.673616450102.issue41247@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20552
pull_request: https://github.com/python/cpython/pull/21403

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:27:52 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 19:27:52 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594236472.59.0.963398087706.issue41247@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20551
pull_request: https://github.com/python/cpython/pull/21402

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:30:41 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 08 Jul 2020 19:30:41 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594236641.93.0.454813487306.issue41247@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> n python to know if there could be a context switch to get_running_loop while set_running_loop is running.


No, it's protected by the GIL.

Good catch, and merged.

----------
nosy: +yselivanov
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:32:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jul 2020 19:32:51 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594236771.7.0.435132753602.issue40170@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for doing this.  I can confirm the performance regression is fixed and that clean code is being generated for PyTuple_Check().

BTW, I support your efforts ? just wanted to make sure we didn't unintentionally take a step backwards.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:37:57 2020
From: report at bugs.python.org (Ben Caller)
Date: Wed, 08 Jul 2020 19:37:57 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594237077.01.0.745137900755.issue39017@roundup.psfhosted.org>


Ben Caller <bcaller at gmail.com> added the comment:

I've attached a minimal tar file which reproduces this. I think the minimum length is 516 bytes.

We need a 512 byte PAX format header block as normal.

Then we need a pax header which matches the regex in https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/tarfile.py#L1243

    length, keyword = re.compile(br"(\d+) ([^=]+)=").groups()

We use the `length` variable to iterate:
https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/tarfile.py#L1271

    while True:
        ...
        pos += length

So we can start the block with "0 X=". This makes length=0. So it will increment pos by 0 each loop and loop the same code forever.

Nice find.

Do you think this denial of service is worth requesting a CVE for? If so, can someone else do it.

----------
nosy: +bc
Added file: https://bugs.python.org/file49309/recursion.tar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:47:28 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 19:47:28 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594237648.37.0.472899524206.issue41247@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fbd71f66843aea71c09656f17a196d29d5d484af by Miss Islington (bot) in branch '3.9':
bpo-41247: asyncio.set_running_loop() cache running loop holder (GH-21401)
https://github.com/python/cpython/commit/fbd71f66843aea71c09656f17a196d29d5d484af


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:03:20 2020
From: report at bugs.python.org (Ben Caller)
Date: Wed, 08 Jul 2020 20:03:20 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594238600.96.0.578853234412.issue39017@roundup.psfhosted.org>


Ben Caller <bcaller at gmail.com> added the comment:

A smaller bug: If instead of 0 you use a large number (> 2^63) e.g. 9999999999999999999 you get `OverflowError: Python int too large to convert to C ssize_t` rather than the expected `tarfile.ReadError` regardless of errorlevel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:04:36 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 20:04:36 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594238676.01.0.17586599043.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

> Program received signal SIGSEGV, Segmentation fault.
0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
128         return ob->ob_type == type;
(gdb) py-bt
Traceback (most recent call first):
  <built-in method compile of module object at remote 0x7fffeabc3a10>
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py", line 306, in parse
    lines.append(next_line)
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py", line 62, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "./src/main/python/pybuilder/python_env.py", line 83, in populate
    python_info = ast.literal_eval(result)
  File "./src/main/python/pybuilder/reactor.py", line 409, in __init__
    self.propagate_property("explicit_namespaces")
  File "./src/main/python/pybuilder/cli.py", line 238, in init_reactor
    reactor = Reactor(logger, execution_manager)
  File "./src/main/python/pybuilder/cli.py", line 415, in main
    reactor = init_reactor(logger)
  File "./src/main/python/pybuilder/__init__.py", line 34, in bootstrap
    sys.exit(pybuilder.cli.main(*sys.argv[1:]))
  File "/tmp/IntegrationTestSupporthzc3tee0/build.py", line 31, in <module>
    bootstrap()
  <built-in method exec of module object at remote 0x7fffeabc3a10>
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 343, in _run_code
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 353, in _run_module_code
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 524, in run_path
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py", line 72, in smoke_test
    return run_path(self.build_py, run_name="__main__")
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", line 30, in test_build_then_clean
    self.smoke_test("-v", "-X", "clean")
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py", line 550, in _callTestMethod
    method()
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py", line 1617, in run
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py", line 653, in __call__
    return self.run(*args, **kwds)
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py", line 378, in run
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py", line 378, in run
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py", line 432, in run
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py", line 783, in runTests
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py", line 101, in __init__
    self.runTests()
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", line 34, in <module>
    unittest.main()
(gdb) py-bt-full
#7 <built-in method compile of module object at remote 0x7fffeabc3a10>
#11 Frame 0xb67600, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated)
    lines.append(next_line)
#18 Frame 0x7fffe92ad230, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated)
    node_or_string = parse(node_or_string, mode='eval')
#25 Frame 0x7fffe9324810, for file ./src/main/python/pybuilder/python_env.py, line 83, in populate (self=<PythonEnv(_env_dir='/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4', _reactor=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f5...(truncated)
    python_info = ast.literal_eval(result)
#32 Frame 0x7fffe98d4810, for file ./src/main/python/pybuilder/reactor.py, line 409, in __init__ (self=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f50>, _plugins=[], _pending_plugin_installs=[], _plugins_imported=set(), _deferred_plugins=<ModuleTraversalTree(_entries={},...(truncated)
    self.propagate_property("explicit_namespaces")
#44 Frame 0x7fffe92aa5c0, for file ./src/main/python/pybuilder/cli.py, line 238, in init_reactor (logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>)
    reactor = Reactor(logger, execution_manager)
#51 Frame 0xd57ab0, for file ./src/main/python/pybuilder/cli.py, line 415, in main (args=('-v', '-X', 'clean'), options=<Values(list_tasks=False, list_plan_tasks=False, start_project=False, update_project=False, project_directory='.', offline=False, environments=[], property_overrides={}, exclude_optional_tasks=[], exclude_all_optional=False, exclude_tasks=[], reset_plugins=False, debug=True, verbose=True, quiet=False, very_quiet=False, force_color=False, no_color=False) at remote 0x7fffe9309be0>, arguments=['clean'], start=<datetime.datetime at remote 0x7fffe98ce2c0>, logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>)
    reactor = init_reactor(logger)
#59 Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys...(truncated)
    sys.exit(pybuilder.cli.main(*sys.argv[1:]))
#66 Frame 0xd49dc0, for file /tmp/IntegrationTestSupporthzc3tee0/build.py, line 31, in <module> ()
    bootstrap()
#74 <built-in method exec of module object at remote 0x7fffeabc3a10>
#78 Frame 0xcaa760, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffe978f110>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module obje...(truncated)
#85 Frame 0xd518f0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffe978f110>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='/tmp/IntegrationTestSupporthzc3tee0/build.py', fname='/tmp/IntegrationTestSupporthzc3tee0/build.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffe98c1dd0>, _saved_module=[<module at remote 0x7fffeab12ad0>]) at remote 0x7fffe9e9c820>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, or...(truncated)
#92 Frame 0xad23d0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='/tmp/IntegrationTestSupporthzc3tee0/build.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffe978f110>, fname='/tmp/IntegrationTestSupporthzc3tee0/build.py')
#99 Frame 0xcfa980, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py, line 72, in smoke_test (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa...(truncated)
    return run_path(self.build_py, run_name="__main__")
#106 Frame 0xa04100, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py, line 30, in test_build_then_clean (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7f...(truncated)
    self.smoke_test("-v", "-X", "clean")
#115 Frame 0x9d3e90, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 550, in _callTestMethod (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDo...(truncated)
    method()
#122 Frame 0x9fb190, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 1617, in run (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cl...(truncated)
#132 Frame 0x7fffea662050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 653, in __call__ (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc...(truncated)
    return self.run(*args, **kwds)
#143 Frame 0x7fffea661810, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 378, in run (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>,...(truncated)
#153 Frame 0x7fffea6a7b30, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 84, in __call__ (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65da...(truncated)
    return self.run(*args, **kwds)
#164 Frame 0x7fffea661620, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 378, in run (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remo...(truncated)
#174 Frame 0x7fffea6a7960, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 84, in __call__ (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at ...(truncated)
    return self.run(*args, **kwds)
#185 Frame 0x9f3b90, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py, line 432, in run (self=<TextTestRunner(stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, descriptions=True, verbosity=1, failfast=False, buffer=False, tb_locals=False, warnings=None) at remote 0x7fffea68ca50>, test=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<...>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remo...(truncated)
#192 Frame 0x7fffea661050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py, line 783, in runTests (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': ...(truncated)
#199 Frame 0x9f0e40, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py, line 101, in __init__ (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': <type ...(truncated)
    self.runTests()
#211 Frame 0x9115d0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py, line 34, in <module> ()
    unittest.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:08:11 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 20:08:11 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594238891.57.0.380878828538.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

(gdb) bt
#0  0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
#1  0x0000000000623487 in _PyType_CheckExact (op=0x0) at ./Include/object.h:641
#2  0x0000000000628d85 in object_recursive_isinstance (tstate=0x8b2210, 
    inst="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", cls=0x0) at Objects/abstract.c:2495
#3  0x0000000000628fdc in PyObject_IsInstance (
    inst="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", cls=0x0) at Objects/abstract.c:2551
#4  0x0000000000682420 in PyAST_Check (
    obj="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85") at Python/Python-ast.c:10356
#5  0x000000000069c754 in builtin_compile_impl (module=<module at remote 0x7fffeabc3a10>, 
    source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", filename='<unknown>', mode=0x7fffeabc42f0 "eval", 
    flags=1024, dont_inherit=0, optimize=-1, feature_version=-1) at Python/bltinmodule.c:784
#6  0x000000000069aa72 in builtin_compile (module=<module at remote 0x7fffeabc3a10>, args=0x7ffffffd7c10, nargs=4, kwnames=('_feature_version',)) at Python/clinic/bltinmodule.c.h:274
#7  0x0000000000655297 in cfunction_vectorcall_FASTCALL_KEYWORDS (func=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0xb677b0, nargsf=9223372036854775812, kwnames=('_feature_version',)) at Objects/methodobject.c:440
#8  0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0xb677b0, nargsf=9223372036854775812, kwnames=('_feature_version',)) at ./Include/cpython/abstract.h:118
#9  0x0000000000509a90 in PyObject_Vectorcall (callable=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0xb677b0, nargsf=9223372036854775812, kwnames=('_feature_version',)) at ./Include/cpython/abstract.h:127
#10 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffd7e78, oparg=5, kwnames=('_feature_version',)) at Python/ceval.c:5044
#11 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0xb67600, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated), throwflag=0)
    at Python/ceval.c:3507
#12 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0xb67600, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#13 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffe978fc70>, 
    globals={'__name__': 'ast', '__doc__': '\n    ast\n    ~~~\n\n    The `ast` module helps Python applications to process trees of the Python\n    abstract syntax grammar.  The abstract syntax itself might change with\n    each Python release; this module helps to find out programmatically what\n    the current grammar looks like and allows modifications of it.\n\n    An abstract syntax tree can be generated by passing `ast.PyCF_ONLY_AST` as\n    a flag to the `compile()` builtin function or by using the `parse()`\n    function from this module.  The result will be a tree of objects whose\n    classes all inherit from `ast.AST`.\n\n    A modified abstract syntax tree can be compiled into a Python code object\n    using the built-in `compile()` function.\n\n    Additionally various helper functions are provided that make working with\n    the trees simpler.  The main intention of the helper functions and this\n    module in general is to provide an easy to use interface for libraries\n    that work tightly with the pyth...(truncated), locals=0x0, 
    args=0x7fffe92ad3c8, argcount=1, kwnames=0x7fffe9762658, kwargs=0x7fffe92ad3d0, kwcount=1, kwstep=1, defs=0x7fffe97662e8, defcount=2, kwdefs={'type_comments': False, 'feature_version': None}, closure=0x0, name='parse', qualname='parse') at Python/ceval.c:4299
#14 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffe9634190>, stack=0x7fffe92ad3c8, nargsf=9223372036854775809, kwnames=('mode',)) at Objects/call.c:395
#15 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffe9634190>, args=0x7fffe92ad3c8, nargsf=9223372036854775809, kwnames=('mode',)) at ./Include/cpython/abstract.h:118
#16 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffe9634190>, args=0x7fffe92ad3c8, nargsf=9223372036854775809, kwnames=('mode',)) at ./Include/cpython/abstract.h:127
#17 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffd9698, oparg=2, kwnames=('mode',)) at Python/ceval.c:5044
#18 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0x7fffe92ad230, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated), throwflag=0)
    at Python/ceval.c:3507
#19 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0x7fffe92ad230, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#20 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffe9633930>, 
    globals={'__name__': 'ast', '__doc__': '\n    ast\n    ~~~\n\n    The `ast` module helps Python applications to process trees of the Python\n    abstract syntax grammar.  The abstract syntax itself might change with\n    each Python release; this module helps to find out programmatically what\n    the current grammar looks like and allows modifications of it.\n\n    An abstract syntax tree can be generated by passing `ast.PyCF_ONLY_AST` as\n    a flag to the `compile()` builtin function or by using the `parse()`\n    function from this module.  The result will be a tree of objects whose\n    classes all inherit from `ast.AST`.\n\n    A modified abstract syntax tree can be compiled into a Python code object\n    using the built-in `compile()` function.\n\n    Additionally various helper functions are provided that make working with\n    the trees simpler.  The main intention of the helper functions and this\n    module in general is to provide an easy to use interface for libraries\n    that work tightly with the pyth...(truncated), locals=0x0, 
    args=0x7fffe93249b8, argcount=1, kwnames=0x0, kwargs=0x7fffe93249c0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='literal_eval', qualname='literal_eval') at Python/ceval.c:4299
#21 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffe9634eb0>, stack=0x7fffe93249b8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:395
#22 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffe9634eb0>, args=0x7fffe93249b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#23 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffe9634eb0>, args=0x7fffe93249b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#24 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffdaed8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#25 0x00000000005193a1 in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0x7fffe9324810, for file ./src/main/python/pybuilder/python_env.py, line 83, in populate (self=<PythonEnv(_env_dir='/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4', _reactor=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f5...(truncated), throwflag=0)
    at Python/ceval.c:3459
#26 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0x7fffe9324810, for file ./src/main/python/pybuilder/python_env.py, line 83, in populate (self=<PythonEnv(_env_dir='/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4', _reactor=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f5...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#27 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffe95d15f0, args=0x7fffe98d49b8, nargs=1, 
    globals={'__name__': 'pybuilder.python_env', '__doc__': None, '__package__': 'pybuilder', '__loader__': <SourceFileLoader(name='pybuilder.python_env', path='./src/main/python/pybuilder/python_env.py') at remote 0x7fffe95ce7d0>, '__spec__': <ModuleSpec(name='pybuilder.python_env', loader=<...>, origin='./src/main/python/pybuilder/python_env.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='./src/main/python/pybuilder/__pycache__/python_env.cpython-39.pyc', _initializing=False) at remote 0x7fffe9307d70>, '__file__': './src/main/python/pybuilder/python_env.py', '__cached__': './src/main/python/pybuilder/__pycache__/python_env.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_sta...(truncated))
    at Objects/call.c:329
#28 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffe9313a50>, stack=0x7fffe98d49b0, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#29 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffe9313a50>, args=0x7fffe98d49b0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#30 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffe9313a50>, args=0x7fffe98d49b0, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#31 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffdc588, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#32 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0x7fffe98d4810, for file ./src/main/python/pybuilder/reactor.py, line 409, in __init__ (self=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f50>, _plugins=[], _pending_plugin_installs=[], _plugins_imported=set(), _deferred_plugins=<ModuleTraversalTree(_entries={},...(truncated), throwflag=0)
    at Python/ceval.c:3476
#33 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0x7fffe98d4810, for file ./src/main/python/pybuilder/reactor.py, line 409, in __init__ (self=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f50>, _plugins=[], _pending_plugin_installs=[], _plugins_imported=set(), _deferred_plugins=<ModuleTraversalTree(_entries={},...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#34 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffe95b5ee0>, 
    globals={'__name__': 'pybuilder.reactor', '__doc__': '\n    The PyBuilder reactor module.\n    Operates a build process by instrumenting an ExecutionManager from the\n    execution module.\n', '__package__': 'pybuilder', '__loader__': <SourceFileLoader(name='pybuilder.reactor', path='./src/main/python/pybuilder/reactor.py') at remote 0x7fffe95a9190>, '__spec__': <ModuleSpec(name='pybuilder.reactor', loader=<...>, origin='./src/main/python/pybuilder/reactor.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='./src/main/python/pybuilder/__pycache__/reactor.cpython-39.pyc', _initializing=False) at remote 0x7fffe95b3f50>, '__file__': './src/main/python/pybuilder/reactor.py', '__cached__': './src/main/python/pybuilder/__pycache__/reactor.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3...(truncated), locals=0x0, 
    args=0x7ffffffddc90, argcount=3, kwnames=0x0, kwargs=0x7ffffffddca8, kwcount=0, kwstep=1, defs=0x7fffe95c55b8, defcount=1, kwdefs=0x0, closure=0x0, name='__init__', qualname='Reactor.__init__') at Python/ceval.c:4299
#35 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffe929f7d0>, stack=0x7ffffffddc90, nargsf=3, kwnames=0x0) at Objects/call.c:395
#36 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0x8b2210, callable=<function at remote 0x7fffe929f7d0>, args=0x7ffffffddc90, nargsf=3, kwargs=0x0) at Objects/call.c:118
#37 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0x8b2210, callable=<function at remote 0x7fffe929f7d0>, 
    obj=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f50>, _plugins=[], _pending_plugin_installs=[], _plugins_imported=set(), _deferred_plugins=<ModuleTraversalTree(_entries={}, _entry_stack=<collections.deque at remote 0x7fffe92ef3d0>, _mods=0) at remote 0x7fffe9309280>, _de...(truncated), 
    args=(<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, <ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>), kwargs=0x0) at Objects/call.c:488
#38 0x00000000004a2aee in slot_tp_init (
    self=<Reactor(logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>, plugin_loader=<DispatchingPluginLoader(logger=<...>, _loaders=(<BuiltinPluginLoader(logger=<...>) at remote 0x7fffe9309af0>, <DownloadingPluginLoader(logger=<...>) at remote 0x7fffe9309b90>)) at remote 0x7fffe9309f50>, _plugins=[], _pending_plugin_installs=[], _plugins_imported=set(), _deferred_plugins=<ModuleTraversalTree(_entries={}, _entry_stack=<collections.deque at remote 0x7fffe92ef3d0>, _mods=0) at remote 0x7fffe9309280>, _de...(truncated), 
    args=(<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, <ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>), kwds=0x0) at Objects/typeobject.c:6927
#39 0x0000000000492464 in type_call (type=0xea6a80, 
    args=(<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, <ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>), kwds=0x0) at Objects/typeobject.c:1026
#40 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0x8b2210, callable=<type at remote 0xea6a80>, args=0x7fffe92aa748, nargs=2, keywords=0x0) at Objects/call.c:191
#41 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<type at remote 0xea6a80>, args=0x7fffe92aa748, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:116
#42 0x0000000000509a90 in PyObject_Vectorcall (callable=<type at remote 0xea6a80>, args=0x7fffe92aa748, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#43 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffddf98, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#44 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0x7fffe92aa5c0, for file ./src/main/python/pybuilder/cli.py, line 238, in init_reactor (logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>), throwflag=0) at Python/ceval.c:3490
#45 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0x7fffe92aa5c0, for file ./src/main/python/pybuilder/cli.py, line 238, in init_reactor (logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>, execution_manager=<ExecutionManager(logger=<...>, _tasks={}, _task_dependencies={}, _dependencies_pending_tasks={}, _actions={}, _execute_before={}, _execute_after={}, _initializers=[], _finalizers=[], _dependencies_resolved=False, _actions_executed=[], _tasks_executed=[], _current_task=None, _current_execution_plan=None, _exclude_optional_tasks=[], _exclude_tasks=[], _exclude_all_optional=False) at remote 0x7fffe9309c80>), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#46 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffe962cd40, args=0xd57c80, nargs=1, 
    globals={'__name__': 'pybuilder.cli', '__doc__': '\n    The PyBuilder cli module.\n    Contains the PyBuilder command-line entrypoint.\n', '__package__': 'pybuilder', '__loader__': <SourceFileLoader(name='pybuilder.cli', path='./src/main/python/pybuilder/cli.py') at remote 0x7fffe98073c0>, '__spec__': <ModuleSpec(name='pybuilder.cli', loader=<...>, origin='./src/main/python/pybuilder/cli.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='./src/main/python/pybuilder/__pycache__/cli.cpython-39.pyc', _initializing=False) at remote 0x7fffe9807e10>, '__file__': './src/main/python/pybuilder/cli.py', '__cached__': './src/main/python/pybuilder/__pycache__/cli.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, o...(truncated))
    at Objects/call.c:329
#47 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffe92a82d0>, stack=0xd57c78, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#48 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffe92a82d0>, args=0xd57c78, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#49 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffe92a82d0>, args=0xd57c78, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#50 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffdf648, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#51 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0xd57ab0, for file ./src/main/python/pybuilder/cli.py, line 415, in main (args=('-v', '-X', 'clean'), options=<Values(list_tasks=False, list_plan_tasks=False, start_project=False, update_project=False, project_directory='.', offline=False, environments=[], property_overrides={}, exclude_optional_tasks=[], exclude_all_optional=False, exclude_tasks=[], reset_plugins=False, debug=True, verbose=True, quiet=False, very_quiet=False, force_color=False, no_color=False) at remote 0x7fffe9309be0>, arguments=['clean'], start=<datetime.datetime at remote 0x7fffe98ce2c0>, logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>), throwflag=0) at Python/ceval.c:3490
#52 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0xd57ab0, for file ./src/main/python/pybuilder/cli.py, line 415, in main (args=('-v', '-X', 'clean'), options=<Values(list_tasks=False, list_plan_tasks=False, start_project=False, update_project=False, project_directory='.', offline=False, environments=[], property_overrides={}, exclude_optional_tasks=[], exclude_all_optional=False, exclude_tasks=[], reset_plugins=False, debug=True, verbose=True, quiet=False, very_quiet=False, force_color=False, no_color=False) at remote 0x7fffe9309be0>, arguments=['clean'], start=<datetime.datetime at remote 0x7fffe98ce2c0>, logger=<ColoredStdOutLogger(filters=[], _name=None, level=10, formatter=None, lock=<_thread.RLock at remote 0x7fffe9309e00>) at remote 0x7fffe9309500>), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#53 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffe95f7930>, 
    globals={'__name__': 'pybuilder.cli', '__doc__': '\n    The PyBuilder cli module.\n    Contains the PyBuilder command-line entrypoint.\n', '__package__': 'pybuilder', '__loader__': <SourceFileLoader(name='pybuilder.cli', path='./src/main/python/pybuilder/cli.py') at remote 0x7fffe98073c0>, '__spec__': <ModuleSpec(name='pybuilder.cli', loader=<...>, origin='./src/main/python/pybuilder/cli.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='./src/main/python/pybuilder/__pycache__/cli.cpython-39.pyc', _initializing=False) at remote 0x7fffe9807e10>, '__file__': './src/main/python/pybuilder/cli.py', '__cached__': './src/main/python/pybuilder/__pycache__/cli.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, o...(truncated), locals=0x0, 
    args=0x7fffe97cf0c8, argcount=3, kwnames=0x0, kwargs=0x7fffe97cf0e0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='main', qualname='main') at Python/ceval.c:4299
#54 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffe92a8c30>, stack=0x7fffe97cf0c8, nargsf=3, kwnames=0x0) at Objects/call.c:395
#55 0x0000000000430faa in PyVectorcall_Call (callable=<function at remote 0x7fffe92a8c30>, tuple=('-v', '-X', 'clean'), kwargs=0x0) at Objects/call.c:230
#56 0x0000000000431155 in _PyObject_Call (tstate=0x8b2210, callable=<function at remote 0x7fffe92a8c30>, args=('-v', '-X', 'clean'), kwargs=0x0) at Objects/call.c:265
#57 0x000000000043123c in PyObject_Call (callable=<function at remote 0x7fffe92a8c30>, args=('-v', '-X', 'clean'), kwargs=0x0) at Objects/call.c:292
#58 0x000000000051ef87 in do_call_core (tstate=0x8b2210, func=<function at remote 0x7fffe92a8c30>, callargs=('-v', '-X', 'clean'), kwdict=0x0) at Python/ceval.c:5092
#59 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0x8b2210, 
    f=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys...(truncated), throwflag=0)
    at Python/ceval.c:3552
#60 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, 
    f=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys=<module at remote 0x7fffeabba2f0>, inspect=<module at remote 0x7fffea2780b0>, BuildFailedException=<type at remote 0xd92460>, current_frame=Frame 0xd01210, for file ./src/main/python/pybuilder/__init__.py, line 34, in bootstrap (sys...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#61 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffe978f1e0, args=0xd49f30, nargs=0, 
    globals={'__name__': 'pybuilder', '__doc__': None, '__package__': 'pybuilder', '__loader__': <SourceFileLoader(name='pybuilder', path='./src/main/python/pybuilder/__init__.py') at remote 0x7fffea275910>, '__spec__': <ModuleSpec(name='pybuilder', loader=<...>, origin='./src/main/python/pybuilder/__init__.py', loader_state=None, submodule_search_locations=['./src/main/python/pybuilder'], _set_fileattr=True, _cached='./src/main/python/pybuilder/__pycache__/__init__.cpython-39.pyc', _initializing=False) at remote 0x7fffea275640>, '__path__': [...], '__file__': './src/main/python/pybuilder/__init__.py', '__cached__': './src/main/python/pybuilder/__pycache__/__init__.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_...(truncated))
    at Objects/call.c:329
#62 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea516230>, stack=0xd49f30, nargsf=9223372036854775808, kwnames=0x0) at Objects/call.c:366
#63 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea516230>, args=0xd49f30, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:118
#64 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea516230>, args=0xd49f30, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#65 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffe2558, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#66 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0xd49dc0, for file /tmp/IntegrationTestSupporthzc3tee0/build.py, line 31, in <module> (), throwflag=0) at Python/ceval.c:3490
#67 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0xd49dc0, for file /tmp/IntegrationTestSupporthzc3tee0/build.py, line 31, in <module> (), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#68 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffe978f110>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), args=0x0, 
    argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
#69 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fffe978f110>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), args=0x0, 
    argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4331
#70 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=<code at remote 0x7fffe978f110>, 
--Type <RET> for more, q to quit, c to continue without paging-- c
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#71 0x000000000050bbc0 in PyEval_EvalCode (co=<code at remote 0x7fffe978f110>, globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated)) at Python/ceval.c:809
#72 0x000000000069ce37 in builtin_exec_impl (module=<module at remote 0x7fffeabc3a10>, source=<code at remote 0x7fffe978f110>, globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated), locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a...(truncated)) at Python/bltinmodule.c:1035
#73 0x000000000069ac76 in builtin_exec (module=<module at remote 0x7fffeabc3a10>, args=0xcaa920, nargs=2) at Python/clinic/bltinmodule.c.h:396
#74 0x00000000006551f4 in cfunction_vectorcall_FASTCALL (func=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0xcaa920, nargsf=9223372036854775810, kwnames=0x0) at Objects/methodobject.c:424
#75 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0xcaa920, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#76 0x0000000000509a90 in PyObject_Vectorcall (callable=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0xcaa920, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#77 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffe3f08, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#78 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0xcaa760, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffe978f110>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module obje...(truncated), throwflag=0) at Python/ceval.c:3490
#79 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0xcaa760, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffe978f110>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module obje...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#80 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea827110>, globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffea82daa0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffea82daf0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, args=0xd51ab8, argcount=7, kwnames=0x0, kwargs=0xd51af0, kwcount=0, kwstep=1, defs=0x7fffea83b7d8, defcount=5, kwdefs=0x0, closure=0x0, name='_run_code', qualname='_run_code') at Python/ceval.c:4299
#81 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8394b0>, stack=0xd51ab8, nargsf=9223372036854775815, kwnames=0x0) at Objects/call.c:395
#82 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8394b0>, args=0xd51ab8, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:118
#83 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea8394b0>, args=0xd51ab8, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:127
#84 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffe5728, oparg=7, kwnames=0x0) at Python/ceval.c:5044
#85 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0xd518f0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffe978f110>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='/tmp/IntegrationTestSupporthzc3tee0/build.py', fname='/tmp/IntegrationTestSupporthzc3tee0/build.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffe98c1dd0>, _saved_module=[<module at remote 0x7fffeab12ad0>]) at remote 0x7fffe9e9c820>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, or...(truncated), throwflag=0) at Python/ceval.c:3490
#86 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0xd518f0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffe978f110>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='/tmp/IntegrationTestSupporthzc3tee0/build.py', fname='/tmp/IntegrationTestSupporthzc3tee0/build.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffe98c1dd0>, _saved_module=[<module at remote 0x7fffeab12ad0>]) at remote 0x7fffe9e9c820>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': '/tmp/IntegrationTestSupporthzc3tee0/build.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c3e50>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c3e50>, or...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#87 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea827520>, globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffea82daa0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffea82daf0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, args=0xad25a0, argcount=3, kwnames=0x7fffea8de658, kwargs=0xad25b8, kwcount=2, kwstep=1, defs=0x7fffea83b848, defcount=5, kwdefs=0x0, closure=0x0, name='_run_module_code', qualname='_run_module_code') at Python/ceval.c:4299
#88 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea7afb90>, stack=0xad25a0, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at Objects/call.c:395
#89 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea7afb90>, args=0xad25a0, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at ./Include/cpython/abstract.h:118
#90 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea7afb90>, args=0xad25a0, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at ./Include/cpython/abstract.h:127
#91 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffe6f38, oparg=5, kwnames=('pkg_name', 'script_name')) at Python/ceval.c:5044
#92 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0xad23d0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='/tmp/IntegrationTestSupporthzc3tee0/build.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffe978f110>, fname='/tmp/IntegrationTestSupporthzc3tee0/build.py'), throwflag=0) at Python/ceval.c:3507
#93 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0xad23d0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='/tmp/IntegrationTestSupporthzc3tee0/build.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffe978f110>, fname='/tmp/IntegrationTestSupporthzc3tee0/build.py'), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#94 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea82eba0>, globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffea82daa0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffea82daf0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, args=0xcfab28, argcount=1, kwnames=0x7fffeaab79c8, kwargs=0xcfab30, kwcount=1, kwstep=1, defs=0x7fffea8de5b8, defcount=2, kwdefs=0x0, closure=0x0, name='run_path', qualname='run_path') at Python/ceval.c:4299
#95 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea7aff50>, stack=0xcfab28, nargsf=9223372036854775809, kwnames=('run_name',)) at Objects/call.c:395
#96 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea7aff50>, args=0xcfab28, nargsf=9223372036854775809, kwnames=('run_name',)) at ./Include/cpython/abstract.h:118
#97 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea7aff50>, args=0xcfab28, nargsf=9223372036854775809, kwnames=('run_name',)) at ./Include/cpython/abstract.h:127
#98 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffe8758, oparg=2, kwnames=('run_name',)) at Python/ceval.c:5044
#99 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0xcfa980, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py, line 72, in smoke_test (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa...(truncated), throwflag=0) at Python/ceval.c:3507
#100 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0xcfa980, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py, line 72, in smoke_test (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#101 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea913110>, globals={'__name__': 'smoke_itest_support', '__doc__': None, '__package__': '', '__loader__': <SourceFileLoader(name='smoke_itest_support', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py') at remote 0x7fffea90ef50>, '__spec__': <ModuleSpec(name='smoke_itest_support', loader=<...>, origin='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/__pycache__/smoke_itest_support.cpython-39.pyc', _initializing=False) at remote 0x7fffea91c280>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_itest_support.py', '__cached__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/__pycache__/smoke_itest_support.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in function...(truncated), locals=0x0, args=0xa04278, argcount=4, kwnames=0x0, kwargs=0xa04298, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='smoke_test', qualname='SmokeIntegrationTestSupport.smoke_test') at Python/ceval.c:4299
#102 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea6ad730>, stack=0xa04278, nargsf=9223372036854775812, kwnames=0x0) at Objects/call.c:395
#103 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea6ad730>, args=0xa04278, nargsf=9223372036854775812, kwnames=0x0) at ./Include/cpython/abstract.h:118
#104 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea6ad730>, args=0xa04278, nargsf=9223372036854775812, kwnames=0x0) at ./Include/cpython/abstract.h:127
#105 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffe9f98, oparg=4, kwnames=0x0) at Python/ceval.c:5044
#106 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0xa04100, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py, line 30, in test_build_then_clean (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7f...(truncated), throwflag=0) at Python/ceval.c:3476
#107 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0xa04100, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py, line 30, in test_build_then_clean (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7f...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#108 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffeaaa2d40, args=0x9d4010, nargs=1, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}) at Objects/call.c:329
#109 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea6ad910>, stack=0x9d4008, nargsf=1, kwnames=0x0) at Objects/call.c:366
#110 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea6ad910>, args=0x9d4008, nargsf=1, kwnames=0x0) at ./Include/cpython/abstract.h:118
#111 0x000000000063c0e6 in method_vectorcall (method=<method at remote 0x7fffea65f4d0>, args=0x9d4010, nargsf=9223372036854775808, kwnames=0x0) at Objects/classobject.c:53
#112 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<method at remote 0x7fffea65f4d0>, args=0x9d4010, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:118
#113 0x0000000000509a90 in PyObject_Vectorcall (callable=<method at remote 0x7fffea65f4d0>, args=0x9d4010, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#114 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffeb748, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#115 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x9d3e90, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 550, in _callTestMethod (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDo...(truncated), throwflag=0) at Python/ceval.c:3490
#116 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x9d3e90, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 550, in _callTestMethod (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDo...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#117 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffea98fa00, args=0x9fb380, nargs=2, globals={'__name__': 'unittest.case', '__doc__': 'Test case implementation', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.case', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py') at remote 0x7fffea986190>, '__spec__': <ModuleSpec(name='unittest.case', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/case.cpython-39.pyc', _initializing=False) at remote 0x7fffea9861e0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/case.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in...(truncated)) at Objects/call.c:329
#118 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e6870>, stack=0x9fb370, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#119 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8e6870>, args=0x9fb370, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#120 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea8e6870>, args=0x9fb370, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#121 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7ffffffece08, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#122 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x9fb190, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 1617, in run (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cl...(truncated), throwflag=0) at Python/ceval.c:3476
#123 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x9fb190, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 1617, in run (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cl...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#124 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea98fd40>, globals={'__name__': 'unittest.case', '__doc__': 'Test case implementation', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.case', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py') at remote 0x7fffea986190>, '__spec__': <ModuleSpec(name='unittest.case', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/case.cpython-39.pyc', _initializing=False) at remote 0x7fffea9861e0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/case.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in...(truncated), locals=0x0, args=0x7ffffffee4f0, argcount=2, kwnames=0x0, kwargs=0x7ffffffee500, kwcount=0, kwstep=1, defs=0x7fffea99c428, defcount=1, kwdefs=0x0, closure=0x0, name='run', qualname='TestCase.run') at Python/ceval.c:4299
#125 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e6a50>, stack=0x7ffffffee4f0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#126 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8e6a50>, args=0x7ffffffee4f0, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#127 0x000000000063c24f in method_vectorcall (method=<method at remote 0x7fffea65f2f0>, args=0x7fffea6b6568, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#128 0x0000000000430faa in PyVectorcall_Call (callable=<method at remote 0x7fffea65f2f0>, tuple=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:230
#129 0x0000000000431155 in _PyObject_Call (tstate=0x8b2210, callable=<method at remote 0x7fffea65f2f0>, args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:265
#130 0x000000000043123c in PyObject_Call (callable=<method at remote 0x7fffea65f2f0>, args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:292
#131 0x000000000051ef87 in do_call_core (tstate=0x8b2210, func=<method at remote 0x7fffea65f2f0>, callargs=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwdict={}) at Python/ceval.c:5092
#132 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x7fffea662050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 653, in __call__ (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc...(truncated), throwflag=0) at Python/ceval.c:3552
#133 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x7fffea662050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py, line 653, in __call__ (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#134 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea993040>, globals={'__name__': 'unittest.case', '__doc__': 'Test case implementation', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.case', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py') at remote 0x7fffea986190>, '__spec__': <ModuleSpec(name='unittest.case', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/case.cpython-39.pyc', _initializing=False) at remote 0x7fffea9861e0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/case.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/case.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in...(truncated), locals=0x0, args=0x7ffffffefe80, argcount=2, kwnames=0x0, kwargs=0x7ffffffefe90, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='__call__', qualname='TestCase.__call__') at Python/ceval.c:4299
#135 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e6c30>, stack=0x7ffffffefe80, nargsf=2, kwnames=0x0) at Objects/call.c:395
#136 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8e6c30>, args=0x7ffffffefe80, nargsf=2, kwargs=0x0) at Objects/call.c:118
#137 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0x8b2210, callable=<function at remote 0x7fffea8e6c30>, obj=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remote 0x85a060>: 'asser...(truncated), args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs=0x0) at Objects/call.c:488
#138 0x00000000004a243a in slot_tp_call (self=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remote 0x85a060>: 'asser...(truncated), args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwds=0x0) at Objects/typeobject.c:6687
#139 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0x8b2210, callable=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remote 0x85a060>: 'asser...(truncated), args=0x7fffea6619b8, nargs=1, keywords=0x0) at Objects/call.c:191
#140 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remote 0x85a060>: 'asser...(truncated), args=0x7fffea6619b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#141 0x0000000000509a90 in PyObject_Vectorcall (callable=<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remote 0x85a060>: 'asser...(truncated), args=0x7fffea6619b8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#142 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7fffffff0138, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#143 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x7fffea661810, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 378, in run (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>,...(truncated), throwflag=0) at Python/ceval.c:3490
#144 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x7fffea661810, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 378, in run (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>,...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#145 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea94f1e0>, globals={'__name__': 'unittest.suite', '__doc__': 'TestSuite', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.suite', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py') at remote 0x7fffea986be0>, '__spec__': <ModuleSpec(name='unittest.suite', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', _initializing=False) at remote 0x7fffea922320>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices...(truncated), locals=0x0, args=0x7fffffff1830, argcount=2, kwnames=0x0, kwargs=0x7fffffff1840, kwcount=0, kwstep=1, defs=0x7fffea8ed0b8, defcount=1, kwdefs=0x0, closure=0x0, name='run', qualname='TestSuite.run') at Python/ceval.c:4299
#146 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8ef410>, stack=0x7fffffff1830, nargsf=2, kwnames=0x0) at Objects/call.c:395
#147 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8ef410>, args=0x7fffffff1830, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#148 0x000000000063c24f in method_vectorcall (method=<method at remote 0x7fffea65f230>, args=0x7fffea6af298, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#149 0x0000000000430faa in PyVectorcall_Call (callable=<method at remote 0x7fffea65f230>, tuple=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:230
#150 0x0000000000431155 in _PyObject_Call (tstate=0x8b2210, callable=<method at remote 0x7fffea65f230>, args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:265
#151 0x000000000043123c in PyObject_Call (callable=<method at remote 0x7fffea65f230>, args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:292
#152 0x000000000051ef87 in do_call_core (tstate=0x8b2210, func=<method at remote 0x7fffea65f230>, callargs=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwdict={}) at Python/ceval.c:5092
#153 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x7fffea6a7b30, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 84, in __call__ (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65da...(truncated), throwflag=0) at Python/ceval.c:3552
#154 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x7fffea6a7b30, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 84, in __call__ (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65da...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#155 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea948930>, globals={'__name__': 'unittest.suite', '__doc__': 'TestSuite', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.suite', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py') at remote 0x7fffea986be0>, '__spec__': <ModuleSpec(name='unittest.suite', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', _initializing=False) at remote 0x7fffea922320>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices...(truncated), locals=0x0, args=0x7fffffff31c0, argcount=2, kwnames=0x0, kwargs=0x7fffffff31d0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='__call__', qualname='BaseTestSuite.__call__') at Python/ceval.c:4299
#156 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8ef2d0>, stack=0x7fffffff31c0, nargsf=2, kwnames=0x0) at Objects/call.c:395
#157 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8ef2d0>, args=0x7fffffff31c0, nargsf=2, kwargs=0x0) at Objects/call.c:118
#158 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0x8b2210, callable=<function at remote 0x7fffea8ef2d0>, obj=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remot...(truncated), args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs=0x0) at Objects/call.c:488
#159 0x00000000004a243a in slot_tp_call (self=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remot...(truncated), args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwds=0x0) at Objects/typeobject.c:6687
#160 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0x8b2210, callable=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remot...(truncated), args=0x7fffea6617c8, nargs=1, keywords=0x0) at Objects/call.c:191
#161 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remot...(truncated), args=0x7fffea6617c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#162 0x0000000000509a90 in PyObject_Vectorcall (callable=<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqual', <type at remot...(truncated), args=0x7fffea6617c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#163 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7fffffff3478, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#164 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x7fffea661620, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 378, in run (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remo...(truncated), throwflag=0) at Python/ceval.c:3490
#165 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x7fffea661620, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 378, in run (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remo...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#166 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea94f1e0>, globals={'__name__': 'unittest.suite', '__doc__': 'TestSuite', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.suite', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py') at remote 0x7fffea986be0>, '__spec__': <ModuleSpec(name='unittest.suite', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', _initializing=False) at remote 0x7fffea922320>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices...(truncated), locals=0x0, args=0x7fffffff4b70, argcount=2, kwnames=0x0, kwargs=0x7fffffff4b80, kwcount=0, kwstep=1, defs=0x7fffea8ed0b8, defcount=1, kwdefs=0x0, closure=0x0, name='run', qualname='TestSuite.run') at Python/ceval.c:4299
#167 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8ef410>, stack=0x7fffffff4b70, nargsf=2, kwnames=0x0) at Objects/call.c:395
#168 0x000000000063bd20 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8ef410>, args=0x7fffffff4b70, nargsf=2, kwnames=0x0) at ./Include/cpython/abstract.h:118
#169 0x000000000063c24f in method_vectorcall (method=<method at remote 0x7fffea65f170>, args=0x7fffea6a2d38, nargsf=1, kwnames=0x0) at Objects/classobject.c:83
#170 0x0000000000430faa in PyVectorcall_Call (callable=<method at remote 0x7fffea65f170>, tuple=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:230
#171 0x0000000000431155 in _PyObject_Call (tstate=0x8b2210, callable=<method at remote 0x7fffea65f170>, args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:265
#172 0x000000000043123c in PyObject_Call (callable=<method at remote 0x7fffea65f170>, args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs={}) at Objects/call.c:292
#173 0x000000000051ef87 in do_call_core (tstate=0x8b2210, func=<method at remote 0x7fffea65f170>, callargs=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwdict={}) at Python/ceval.c:5092
#174 0x0000000000519c2c in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x7fffea6a7960, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 84, in __call__ (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at ...(truncated), throwflag=0) at Python/ceval.c:3552
#175 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x7fffea6a7960, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py, line 84, in __call__ (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at ...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#176 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea948930>, globals={'__name__': 'unittest.suite', '__doc__': 'TestSuite', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.suite', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py') at remote 0x7fffea986be0>, '__spec__': <ModuleSpec(name='unittest.suite', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', _initializing=False) at remote 0x7fffea922320>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/suite.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/suite.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices...(truncated), locals=0x0, args=0x7fffffff6500, argcount=2, kwnames=0x0, kwargs=0x7fffffff6510, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='__call__', qualname='BaseTestSuite.__call__') at Python/ceval.c:4299
#177 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8ef2d0>, stack=0x7fffffff6500, nargsf=2, kwnames=0x0) at Objects/call.c:395
#178 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea8ef2d0>, args=0x7fffffff6500, nargsf=2, kwargs=0x0) at Objects/call.c:118
#179 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0x8b2210, callable=<function at remote 0x7fffea8ef2d0>, obj=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqu...(truncated), args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwargs=0x0) at Objects/call.c:488
#180 0x00000000004a243a in slot_tp_call (self=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqu...(truncated), args=(<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>,), kwds=0x0) at Objects/typeobject.c:6687
#181 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0x8b2210, callable=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqu...(truncated), args=0x9f3d88, nargs=1, keywords=0x0) at Objects/call.c:191
#182 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqu...(truncated), args=0x9f3d88, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:116
#183 0x0000000000509a90 in PyObject_Vectorcall (callable=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x9f0a60>) at remote 0x7fffea65d5a0>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffea65daa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, _type_equality_funcs={<type at remote 0x85b260>: 'assertDictEqu...(truncated), args=0x9f3d88, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#184 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7fffffff67b8, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#185 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x9f3b90, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py, line 432, in run (self=<TextTestRunner(stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, descriptions=True, verbosity=1, failfast=False, buffer=False, tb_locals=False, warnings=None) at remote 0x7fffea68ca50>, test=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<...>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remo...(truncated), throwflag=0) at Python/ceval.c:3490
#186 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x9f3b90, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py, line 432, in run (self=<TextTestRunner(stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7fffeab116e0>) at remote 0x7fffea65d910>, descriptions=True, verbosity=1, failfast=False, buffer=False, tb_locals=False, warnings=None) at remote 0x7fffea68ca50>, test=<TestSuite(_tests=[<TestSuite(_tests=[<CleanSmokeTest(_testMethodName='test_build_then_clean', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=1, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7fffeab115f0>, _original_stderr=<_io.TextIOWrapper at remote 0x7fffeab116e0>, _mirrorOutput=False, stream=<...>, showAll=False, dots=True, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remo...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#187 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffea91be10, args=0x7fffea6611e0, nargs=2, globals={'__name__': 'unittest.runner', '__doc__': 'Running tests', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.runner', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py') at remote 0x7fffea915be0>, '__spec__': <ModuleSpec(name='unittest.runner', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/runner.cpython-39.pyc', _initializing=False) at remote 0x7fffea915d20>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/runner.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/runner.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `.....(truncated)) at Objects/call.c:329
#188 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea838910>, stack=0x7fffea6611d0, nargsf=9223372036854775810, kwnames=0x0) at Objects/call.c:366
#189 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea838910>, args=0x7fffea6611d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#190 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea838910>, args=0x7fffea6611d0, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#191 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7fffffff7e78, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#192 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x7fffea661050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py, line 783, in runTests (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': ...(truncated), throwflag=0) at Python/ceval.c:3476
#193 0x00000000004304c0 in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x7fffea661050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py, line 783, in runTests (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': ...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#194 0x0000000000431372 in function_code_fastcall (tstate=0x8b2210, co=0x7fffea9031e0, args=0x9f1028, nargs=1, globals={'__name__': 'unittest.main', '__doc__': 'Unittest main program', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.main', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py') at remote 0x7fffea8fce10>, '__spec__': <ModuleSpec(name='unittest.main', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/main.cpython-39.pyc', _initializing=False) at remote 0x7fffea8fce60>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/main.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in sl...(truncated)) at Objects/call.c:329
#195 0x00000000004315c0 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea839230>, stack=0x9f1020, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:366
#196 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea839230>, args=0x9f1020, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#197 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea839230>, args=0x9f1020, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#198 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7fffffff9528, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#199 0x000000000051940d in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x9f0e40, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py, line 101, in __init__ (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': <type ...(truncated), throwflag=0) at Python/ceval.c:3476
#200 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x9f0e40, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py, line 101, in __init__ (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': <type ...(truncated), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#201 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffea8f9930>, globals={'__name__': 'unittest.main', '__doc__': 'Unittest main program', '__package__': 'unittest', '__loader__': <SourceFileLoader(name='unittest.main', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py') at remote 0x7fffea8fce10>, '__spec__': <ModuleSpec(name='unittest.main', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/main.cpython-39.pyc', _initializing=False) at remote 0x7fffea8fce60>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/main.py', '__cached__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/unittest/__pycache__/main.cpython-39.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in sl...(truncated), locals=0x0, args=0x7fffffffac30, argcount=1, kwnames=0x0, kwargs=0x7fffffffac38, kwcount=0, kwstep=1, defs=0x7fffea838b08, defcount=11, kwdefs={'tb_locals': False}, closure=0x0, name='__init__', qualname='TestProgram.__init__') at Python/ceval.c:4299
#202 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea838b90>, stack=0x7fffffffac30, nargsf=1, kwnames=0x0) at Objects/call.c:395
#203 0x0000000000430a8c in _PyObject_FastCallDictTstate (tstate=0x8b2210, callable=<function at remote 0x7fffea838b90>, args=0x7fffffffac30, nargsf=1, kwargs=0x0) at Objects/call.c:118
#204 0x0000000000431b83 in _PyObject_Call_Prepend (tstate=0x8b2210, callable=<function at remote 0x7fffea838b90>, obj=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': <type at remote 0x99d6c0>, 'extend': <type at remote 0x99daa0>}, 'type': {None: <function at remote 0x7fffea6580f0>}}, _actions=[<_HelpAc...(truncated), args=(), kwargs=0x0) at Objects/call.c:488
#205 0x00000000004a2aee in slot_tp_init (self=<TestProgram(module=<module at remote 0x7fffeab12ad0>, exit=True, failfast=False, catchbreak=False, verbosity=1, buffer=False, tb_locals=False, warnings=None, defaultTest=None, testRunner=<type at remote 0x9ab0e0>, testLoader=<TestLoader(errors=[], _loading_packages=set()) at remote 0x7fffea8fca00>, progName='smoke_clean_tests.py', testNamePatterns=[], _main_parser=<ArgumentParser(description=None, argument_default=None, prefix_chars='-', conflict_handler='error', _registries={'action': {None: <type at remote 0x99ab00>, 'store': <type at remote 0x99ab00>, 'store_const': <type at remote 0x99aee0>, 'store_true': <type at remote 0x99b2c0>, 'store_false': <type at remote 0x99b6a0>, 'append': <type at remote 0x99ba80>, 'append_const': <type at remote 0x99be60>, 'count': <type at remote 0x99c240>, 'help': <type at remote 0x99c620>, 'version': <type at remote 0x99ca00>, 'parsers': <type at remote 0x99d6c0>, 'extend': <type at remote 0x99daa0>}, 'type': {None: <function at remote 0x7fffea6580f0>}}, _actions=[<_HelpAc...(truncated), args=(), kwds=0x0) at Objects/typeobject.c:6927
#206 0x0000000000492464 in type_call (type=0x9abde0, args=(), kwds=0x0) at Objects/typeobject.c:1026
#207 0x0000000000430db7 in _PyObject_MakeTpCall (tstate=0x8b2210, callable=<type at remote 0x9abde0>, args=0x911748, nargs=0, keywords=0x0) at Objects/call.c:191
#208 0x0000000000509a15 in _PyObject_VectorcallTstate (tstate=0x8b2210, callable=<type at remote 0x9abde0>, args=0x911748, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:116
#209 0x0000000000509a90 in PyObject_Vectorcall (callable=<type at remote 0x9abde0>, args=0x911748, nargsf=9223372036854775808, kwnames=0x0) at ./Include/cpython/abstract.h:127
#210 0x000000000051ea52 in call_function (tstate=0x8b2210, pp_stack=0x7fffffffaf48, oparg=0, kwnames=0x0) at Python/ceval.c:5044
#211 0x00000000005193a1 in _PyEval_EvalFrameDefault (tstate=0x8b2210, f=Frame 0x9115d0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py, line 34, in <module> (), throwflag=0) at Python/ceval.c:3459
#212 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b2210, f=Frame 0x9115d0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py, line 34, in <module> (), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#213 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b2210, _co=<code at remote 0x7fffeaaa5860>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
#214 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fffeaaa5860>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4331
#215 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=<code at remote 0x7fffeaaa5860>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#216 0x000000000050bbc0 in PyEval_EvalCode (co=<code at remote 0x7fffeaaa5860>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}) at Python/ceval.c:809
#217 0x000000000056eaf9 in run_eval_code_obj (tstate=0x8b2210, co=0x7fffeaaa5860, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}) at Python/pythonrun.c:1178
#218 0x000000000056ebe2 in run_mod (mod=0x930df8, filename='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, flags=0x7fffffffc948, arena=0x7fffeaaa7a60) at Python/pythonrun.c:1199
#219 0x000000000056e971 in PyRun_FileExFlags (fp=0x8af110, filename_str=0x7fffeaaa81a0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", start=257, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py', '__cached__': None, 'unittest': <module at remote 0x7fffeaa92890>, 'SmokeIntegrationTestSupport': <type at remote 0x9f01f0>, 'CleanSmokeTest': <type at remote 0x9f0a60>}, closeit=1, flags=0x7fffffffc948) at Python/pythonrun.c:1116
#220 0x000000000056d447 in PyRun_SimpleFileExFlags (fp=0x8af110, filename=0x7fffeaaa81a0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", closeit=1, flags=0x7fffffffc948) at Python/pythonrun.c:438
#221 0x000000000056c958 in PyRun_AnyFileExFlags (fp=0x8af110, filename=0x7fffeaaa81a0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/src/integrationtest/python/smoke_clean_tests.py", closeit=1, flags=0x7fffffffc948) at Python/pythonrun.c:87
#222 0x000000000041e6e8 in pymain_run_file (config=0x8b0990, cf=0x7fffffffc948) at Modules/main.c:369
#223 0x000000000041ecd8 in pymain_run_python (exitcode=0x7fffffffc98c) at Modules/main.c:594
#224 0x000000000041edc9 in Py_RunMain () at Modules/main.c:673
#225 0x000000000041ee43 in pymain_main (args=0x7fffffffc9f0) at Modules/main.c:703
#226 0x000000000041eebd in Py_BytesMain (argc=2, argv=0x7fffffffcb28) at Modules/main.c:727
#227 0x000000000041d786 in main (argc=2, argv=0x7fffffffcb28) at ./Programs/python.c:15

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:39:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 20:39:48 +0000
Subject: [issue41175] Static analysis issues reported by GCC 10
In-Reply-To: <1593540409.36.0.220720333967.issue41175@roundup.psfhosted.org>
Message-ID: <1594240788.54.0.252466237031.issue41175@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 61fc23ca106bc82955b0e59d1ab42285b94899e2 by stratakis in branch 'master':
bpo-41175: Guard against a NULL pointer dereference within bytearrayobject (GH-21240)
https://github.com/python/cpython/commit/61fc23ca106bc82955b0e59d1ab42285b94899e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41175>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:44:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 20:44:25 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594241065.64.0.822995406911.issue41194@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I'm reopening this as the original SEGV didn't go away in 3.9 beta 4. It looks like debug build caught an assertion and prevented the SEGV from triggering.

Right, the fix was merged after v3.9.0b4 was merged.

The fix will be part of the next 3.9 release ("3.9.0 beta 5: Monday, 2020-07-20"). Usually, issues are closed when fixes are merged, not when new versions including the fix are released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:46:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 20:46:37 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594241197.91.0.732433745573.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Thanks for doing this.  I can confirm the performance regression is fixed and that clean code is being generated for PyTuple_Check().

Thanks for checking!

> BTW, I support your efforts ? just wanted to make sure we didn't unintentionally take a step backwards.

I tried to avoid changes which could affect performances.

I wrote PEP 620 for such changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:46:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 20:46:58 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594241218.78.0.64687065938.issue40360@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:48:04 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 20:48:04 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594241283.99.0.606239681077.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

@vstinner, this is in the current 3.9 as of a0a6f1167834c87f12e2eca11dd77143103e7691 (11hrs ago). We didn't get the actual bug, we just got stopped by an assertion when python got built with debug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:56:36 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 08 Jul 2020 20:56:36 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594241796.47.0.447869776614.issue41202@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Yep, having to set a custom exception handler definitely constitutes as needing "finer control over the event loop behavior". There's absolute nothing wrong with using the low-level API when you need further customization, but we try to minimize the high-level API as much as possible to make it simple for the average user. I suspect that the majority of asyncio users don't have a need to customize the exception handler beyond the default settings.

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:58:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jul 2020 20:58:22 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594241902.79.0.751096247921.issue41194@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I checked manually that msg372859 example is fixed.

> @vstinner, this is in the current 3.9 as of a0a6f1167834c87f12e2eca11dd77143103e7691 (11hrs ago). We didn't get the actual bug, we just got stopped by an assertion when python got built with debug.

It sounds like a different bug. Can you provide a reproducer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:00:43 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 21:00:43 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594242043.55.0.536356619284.issue40597@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4fa61a7732923f92de0f7830c12da48c4cec937f by Mark Sapiro in branch 'master':
bpo-40597: Allow email.contextmanager set_content() to set a null string. (GH-20542)
https://github.com/python/cpython/commit/4fa61a7732923f92de0f7830c12da48c4cec937f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:00:56 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 21:00:56 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594242056.84.0.914885398188.issue40597@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20553
pull_request: https://github.com/python/cpython/pull/21404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:01:04 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 21:01:04 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594242064.17.0.819946588812.issue40597@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20554
pull_request: https://github.com/python/cpython/pull/21405

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:02:51 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 21:02:51 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594242171.23.0.0985163125824.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

I'm working on a short reproducer, but otherwise reproducer is exactly the same as described in https://bugs.python.org/issue41194#msg372854

The way I bumped into this is trying to confirm the fix in Beta 4 (which apparently didn't make it, as you mentioned).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:07:20 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 21:07:20 +0000
Subject: [issue41093] TCPServer's server_forever() shutdown immediately when
 calling shutdown()
In-Reply-To: <1592938873.08.0.742314253675.issue41093@roundup.psfhosted.org>
Message-ID: <1594242440.0.0.782013227484.issue41093@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

bump

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41093>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:18:45 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 21:18:45 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594243125.61.0.304770502077.issue40597@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c1c50345933efca42169f03d79ff4fe3d9c06bdc by Miss Islington (bot) in branch '3.8':
bpo-40597: Allow email.contextmanager set_content() to set a null string. (GH-20542)
https://github.com/python/cpython/commit/c1c50345933efca42169f03d79ff4fe3d9c06bdc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:21:05 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jul 2020 21:21:05 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594243265.49.0.594813084879.issue40597@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e68978978f49cfc489fa0f888281ce84460818c0 by Miss Islington (bot) in branch '3.9':
bpo-40597: Allow email.contextmanager set_content() to set a null string. (GH-20542)
https://github.com/python/cpython/commit/e68978978f49cfc489fa0f888281ce84460818c0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:26:03 2020
From: report at bugs.python.org (Tony)
Date: Wed, 08 Jul 2020 21:26:03 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594243563.99.0.696601379001.issue41247@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
pull_requests: +20555
pull_request: https://github.com/python/cpython/pull/21406

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:29:56 2020
From: report at bugs.python.org (Cooper Lees)
Date: Wed, 08 Jul 2020 21:29:56 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1594243796.6.0.696602034262.issue37179@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

Another bump since I've waiting over a year. Any plans for this? Will it make 3.10? Anything I can do?

----------
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:11:19 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 22:11:19 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594246279.6.0.938698783076.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

"Short" reproducer:


repro.py:

```
import sys
from os import getcwd, chdir
from runpy import run_path


def smoke_test(script, *args):
    old_argv = list(sys.argv)
    del sys.argv[:]
    sys.argv.append(script)
    sys.argv.extend(args)

    old_modules = dict(sys.modules)
    old_meta_path = list(sys.meta_path)
    old_cwd = getcwd()

    try:
        return run_path(script, run_name="__main__")
    except SystemExit as e:
        if e.code:
            print("Test did not exit successfully")
    finally:
        del sys.argv[:]
        sys.argv.extend(old_argv)

        sys.modules.clear()
        sys.modules.update(old_modules)

        del sys.meta_path[:]
        sys.meta_path.extend(old_meta_path)
        chdir(old_cwd)


smoke_test("script.py")

smoke_test("script.py")
```

script.py:

```
import sys
import subprocess    
import ast

_PYTHON_INFO_SCRIPT = """import platform, sys, os, sysconfig
_executable = os.path.normcase(os.path.abspath(getattr(sys, "_base_executable", sys.executable)))
_platform = sys.platform
if _platform == "linux2":
    _platform = "linux"
print({
    "_platform": _platform,
    "_os_name": os.name,
    "_executable": (_executable, ),
    "_exec_dir": os.path.normcase(os.path.abspath(os.path.dirname(_executable))),
    "_name": platform.python_implementation(),
    "_type": platform.python_implementation().lower(),
    "_version": tuple(sys.version_info),
    "_is_pypy": "__pypy__" in sys.builtin_module_names,
    "_is_64bit": (getattr(sys, "maxsize", None) or getattr(sys, "maxint")) > 2 ** 32,
    "_versioned_dir_name": "%s-%s" % (platform.python_implementation().lower(), ".".join(str(f) for f in sys.version_info)),
    "_environ": dict(os.environ),
    "_darwin_python_framework": sysconfig.get_config_var("PYTHONFRAMEWORK")
})
"""

result = subprocess.check_output([sys.executable, "-c", _PYTHON_INFO_SCRIPT], universal_newlines=True)
python_info = ast.literal_eval(result)
print(python_info)

```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:12:41 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Wed, 08 Jul 2020 22:12:41 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594246361.11.0.564160983566.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

$ PYTHONWARNINGS=ignore gdb --args /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python ./repro.py 
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python...
(gdb) run
Starting program: /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python ./repro.py
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.31-2.fc32.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 185113]
{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac8589a5eebfb3e6b0', 'DEV_HOME': '/home/arcivanov/devhome/current', 'MY_RUBY_HOME': '/home/arcivanov/.rvm/rubies/ruby-2.4.3', 'ANT_HOME': '/home/arcivanov/devhome/current/ant', 'XDM_MANAGED': 'method=classic', 'DESKTOP_SESSION': 'default', 'RBENV_SHELL': 'bash', 'SSH_AGENT_PID': '5854', 'GTK_RC_FILES': '/etc/gtk/gtkrc:/home/arcivanov/.gtkrc:/home/arcivanov/.config/gtkrc', 'GDK_CORE_DEVICE_EVENTS': '1', 'XCURSOR_SIZE': '32', 'RUBY_VERSION': 'ruby-2.4.3', 'XDG_SEAT': 'seat0', 'PWD': '/home/arcivanov/Documents/src/arcivanov/pybuilder', 'PYENV_VIRTUALENV_INIT': '1', 'LOGNAME': 'arcivanov', 'XDG_SESSION_TYPE': 'x11', 'MODULESHOME': '/usr/share/Modules', 'rvm_version': '1.29.10 (latest)', 'MANPATH': '/home/arcivanov/devhome/current/jdk/man:/home/arcivanov/devhome/current/postgres-xl/share/man:/home/arcivanov/devhome/current/haproxy/share/man:/home/arcivanov/devhome/current/jdk/man:/home/arcivanov/devhome/current/postgres-xl/share/man:/home/arcivanov/devhome/current/haproxy/share/man::', '_': '/usr/bin/gdb', 'XAUTHORITY': '/tmp/xauth-1000-_0', 'SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS': '0', 'WINDOWPATH': '1', 'LINES': '221', 'GTK2_RC_FILES': '/etc/gtk-2.0/gtkrc:/home/arcivanov/.gtkrc-2.0:/home/arcivanov/.gtkrc-2.0-kde4:/home/arcivanov/.config/gtkrc-2.0', 'HOME': '/home/arcivanov', 'SSH_ASKPASS': '/usr/bin/ksshaskpass', 'LANG': 'en_US.UTF-8', 'LS_COLORS': 'rs=0:di=38;5;33:ln=38;5;51:mh=00:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=01;37;41:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;40:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.zst=38;5;9:*.tzst=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.wim=38;5;9:*.swm=38;5;9:*.dwm=38;5;9:*.esd=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.mjpg=38;5;13:*.mjpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.webp=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:', 'XDG_CURRENT_DESKTOP': 'KDE', 'KONSOLE_DBUS_SERVICE': ':1.34', 'COLUMNS': '267', 'VIRTUAL_ENV': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/envs/pyb-3.9-dev-d', 'KONSOLE_DBUS_SESSION': '/Sessions/7', 'PROFILEHOME': '', 'M2_HOME': '/home/arcivanov/devhome/current/maven', 'KONSOLE_VERSION': '200401', 'STEAM_FRAME_FORCE_CLOSE': '1', 'KDE_SESSION_UID': '1000', 'rvm_bin_path': '/home/arcivanov/.rvm/bin', 'GEM_PATH': '/home/arcivanov/.rvm/gems/ruby-2.4.3:/home/arcivanov/.rvm/gems/ruby-2.4.3 at global', 'GEM_HOME': '/home/arcivanov/.rvm/gems/ruby-2.4.3', 'MODULEPATH_modshare': '/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1', 'XDG_SESSION_CLASS': 'user', 'TERM': 'xterm-256color', 'LESSOPEN': '||/usr/bin/lesspipe.sh %s', 'USER': 'arcivanov', 'COLORFGBG': '15;0', 'MODULES_RUN_QUARANTINE': 'LD_LIBRARY_PATH', 'KDE_SESSION_VERSION': '5', 'PAM_KWALLET5_LOGIN': '/run/user/1000/kwallet5.socket', 'MAVEN_HOME': '/home/arcivanov/devhome/current/maven', 'LOADEDMODULES': '', 'DISPLAY': ':0', 'SHLVL': '1', 'XDG_VTNR': '1', 'XDG_SESSION_ID': '1', 'XDG_RUNTIME_DIR': '/run/user/1000', 'DM_CONTROL': '/var/run/xdmctl', 'PYENV_ROOT': '/home/arcivanov/.pyenv', 'KDEDIRS': '/usr', 'MAVEN_OPTS': '', 'QT_AUTO_SCREEN_SCALE_FACTOR': '0', 'XCURSOR_THEME': 'Adwaita', 'XDG_DATA_DIRS': '/home/arcivanov/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share', 'KDE_FULL_SESSION': 'true', 'PATH': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/envs/pyb-3.9-dev-d/bin:/home/arcivanov/.pyenv/plugins/pyenv-virtualenv/shims:/home/arcivanov/.pyenv/shims:/home/arcivanov/.pyenv/bin:/home/arcivanov/.rbenv/shims:/home/arcivanov/.rbenv/bin:/home/arcivanov/.rvm/gems/ruby-2.4.3/bin:/home/arcivanov/.rvm/gems/ruby-2.4.3 at global/bin:/home/arcivanov/.rvm/rubies/ruby-2.4.3/bin:/home/arcivanov/devhome/current/jdk/bin:/home/arcivanov/devhome/current/ant/bin:/home/arcivanov/devhome/current/maven/bin:/home/arcivanov/.pyenv/plugins/pyenv-virtualenv/shims:/home/arcivanov/.pyenv/shims:/home/arcivanov/.pyenv/bin:/home/arcivanov/.rbenv/shims:/home/arcivanov/.rbenv/bin:/home/arcivanov/devhome/current/jdk/bin:/home/arcivanov/devhome/current/ant/bin:/home/arcivanov/devhome/current/maven/bin:/usr/share/Modules/bin:/usr/lib64/ccache:/home/arcivanov/.rvm/gems/ruby-2.4.3/bin:/home/arcivanov/.rvm/gems/ruby-2.4.3 at global/bin:/home/arcivanov/.rvm/rubies/ruby-2.4.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/arcivanov/.rvm/bin:/usr/local/sbin:/usr/sbin', 'MODULEPATH': '/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles', 'DBUS_SESSION_BUS_ADDRESS': 'unix:path=/run/user/1000/bus', 'PYTHONWARNINGS': 'ignore', 'MAIL': '/var/spool/mail/arcivanov', 'IRBRC': '/home/arcivanov/.rvm/rubies/ruby-2.4.3/.irbrc', 'rvm_path': '/home/arcivanov/.rvm', 'OLDPWD': '/home/arcivanov/Documents/src', 'MODULES_CMD': '/usr/share/Modules/libexec/modulecmd.tcl', 'BASH_FUNC_switchml%%': '() {  typeset swfound=1;\n if [ "${MODULES_USE_COMPAT_VERSION:-0}" = \'1\' ]; then\n typeset swname=\'main\';\n if [ -e /usr/share/Modules/libexec/modulecmd.tcl ]; then\n typeset swfound=0;\n unset MODULES_USE_COMPAT_VERSION;\n fi;\n else\n typeset swname=\'compatibility\';\n if [ -e /usr/share/Modules/libexec/modulecmd-compat ]; then\n typeset swfound=0;\n MODULES_USE_COMPAT_VERSION=1;\n export MODULES_USE_COMPAT_VERSION;\n fi;\n fi;\n if [ $swfound -eq 0 ]; then\n echo "Switching to Modules $swname version";\n source /usr/share/Modules/init/bash;\n else\n echo "Cannot switch to Modules $swname version, command not found";\n return 1;\n fi\n}', 'BASH_FUNC_module%%': '() {  _module_raw "$@" 2>&1\n}', 'BASH_FUNC_scl%%': '() {  if [ "$1" = "load" -o "$1" = "unload" ]; then\n eval "module $@";\n else\n /usr/bin/scl "$@";\n fi\n}', 'BASH_FUNC__module_raw%%': '() {  unset _mlshdbg;\n if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = \'1\' ]; then\n case "$-" in \n *v*x*)\n set +vx;\n _mlshdbg=\'vx\'\n ;;\n *v*)\n set +v;\n _mlshdbg=\'v\'\n ;;\n *x*)\n set +x;\n _mlshdbg=\'x\'\n ;;\n *)\n _mlshdbg=\'\'\n ;;\n esac;\n fi;\n unset _mlre _mlIFS;\n if [ -n "${IFS+x}" ]; then\n _mlIFS=$IFS;\n fi;\n IFS=\' \';\n for _mlv in ${MODULES_RUN_QUARANTINE:-};\n do\n if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then\n if [ -n "`eval \'echo ${\'$_mlv\'+x}\'`" ]; then\n _mlre="${_mlre:-}${_mlv}_modquar=\'`eval \'echo ${\'$_mlv\'}\'`\' ";\n fi;\n _mlrv="MODULES_RUNENV_${_mlv}";\n _mlre="${_mlre:-}${_mlv}=\'`eval \'echo ${\'$_mlrv\':-}\'`\' ";\n fi;\n done;\n if [ -n "${_mlre:-}" ]; then\n eval `eval ${_mlre}/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash \'"$@"\'`;\n else\n eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;\n fi;\n _mlstatus=$?;\n if [ -n "${_mlIFS+x}" ]; then\n IFS=$_mlIFS;\n else\n unset IFS;\n fi;\n unset _mlre _mlv _mlrv _mlIFS;\n if [ -n "${_mlshdbg:-}" ]; then\n set -$_mlshdbg;\n fi;\n unset _mlshdbg;\n return $_mlstatus\n}'}, '_darwin_python_framework': ''}
[Detaching after fork from child process 185114]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
128         return ob->ob_type == type;
Missing separate debuginfos, use: dnf debuginfo-install libxcrypt-4.4.16-3.fc32.x86_64
(gdb) 
(gdb) bt
#0  0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
#1  0x0000000000623487 in _PyType_CheckExact (op=0x0) at ./Include/object.h:641
#2  0x0000000000628d85 in object_recursive_isinstance (tstate=0x8b19a0, 
    inst="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", cls=0x0) at Objects/abstract.c:2495
#3  0x0000000000628fdc in PyObject_IsInstance (
    inst="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", cls=0x0) at Objects/abstract.c:2551
#4  0x0000000000682420 in PyAST_Check (
    obj="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85") at Python/Python-ast.c:10356
#5  0x000000000069c754 in builtin_compile_impl (module=<module at remote 0x7fffeabc3a10>, 
    source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", filename='<unknown>', mode=0x7fffeabc42f0 "eval", 
    flags=1024, dont_inherit=0, optimize=-1, feature_version=-1) at Python/bltinmodule.c:784
#6  0x000000000069aa72 in builtin_compile (module=<module at remote 0x7fffeabc3a10>, args=0x7fffffff02b0, nargs=4, kwnames=('_feature_version',)) at Python/clinic/bltinmodule.c.h:274
#7  0x0000000000655297 in cfunction_vectorcall_FASTCALL_KEYWORDS (func=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0x9c8a00, nargsf=9223372036854775812, kwnames=('_feature_version',)) at Objects/methodobject.c:440
#8  0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0x9c8a00, nargsf=9223372036854775812, kwnames=('_feature_version',)) at ./Include/cpython/abstract.h:118
#9  0x0000000000509a90 in PyObject_Vectorcall (callable=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0x9c8a00, nargsf=9223372036854775812, kwnames=('_feature_version',)) at ./Include/cpython/abstract.h:127
#10 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff0518, oparg=5, kwnames=('_feature_version',)) at Python/ceval.c:5044
#11 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x9c8850, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated), throwflag=0)
    at Python/ceval.c:3507
#12 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x9c8850, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#13 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffea863ee0>, 
    globals={'__name__': 'ast', '__doc__': '\n    ast\n    ~~~\n\n    The `ast` module helps Python applications to process trees of the Python\n    abstract syntax grammar.  The abstract syntax itself might change with\n    each Python release; this module helps to find out programmatically what\n    the current grammar looks like and allows modifications of it.\n\n    An abstract syntax tree can be generated by passing `ast.PyCF_ONLY_AST` as\n    a flag to the `compile()` builtin function or by using the `parse()`\n    function from this module.  The result will be a tree of objects whose\n    classes all inherit from `ast.AST`.\n\n    A modified abstract syntax tree can be compiled into a Python code object\n    using the built-in `compile()` function.\n\n    Additionally various helper functions are provided that make working with\n    the trees simpler.  The main intention of the helper functions and this\n    module in general is to provide an easy to use interface for libraries\n    that work tightly with the pyth...(truncated), locals=0x0, 
    args=0x7fffea8161e8, argcount=1, kwnames=0x7fffea7fc3d8, kwargs=0x7fffea8161f0, kwcount=1, kwstep=1, defs=0x7fffea8ab978, defcount=2, kwdefs={'type_comments': False, 'feature_version': None}, closure=0x0, name='parse', qualname='parse') at Python/ceval.c:4299
#14 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea7cc410>, stack=0x7fffea8161e8, nargsf=9223372036854775809, kwnames=('mode',)) at Objects/call.c:395
#15 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea7cc410>, args=0x7fffea8161e8, nargsf=9223372036854775809, kwnames=('mode',)) at ./Include/cpython/abstract.h:118
#16 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea7cc410>, args=0x7fffea8161e8, nargsf=9223372036854775809, kwnames=('mode',)) at ./Include/cpython/abstract.h:127
#17 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff1d38, oparg=2, kwnames=('mode',)) at Python/ceval.c:5044
#18 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x7fffea816050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated), throwflag=0)
    at Python/ceval.c:3507
#19 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x7fffea816050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#20 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffea876930>, 
    globals={'__name__': 'ast', '__doc__': '\n    ast\n    ~~~\n\n    The `ast` module helps Python applications to process trees of the Python\n    abstract syntax grammar.  The abstract syntax itself might change with\n    each Python release; this module helps to find out programmatically what\n    the current grammar looks like and allows modifications of it.\n\n    An abstract syntax tree can be generated by passing `ast.PyCF_ONLY_AST` as\n    a flag to the `compile()` builtin function or by using the `parse()`\n    function from this module.  The result will be a tree of objects whose\n    classes all inherit from `ast.AST`.\n\n    A modified abstract syntax tree can be compiled into a Python code object\n    using the built-in `compile()` function.\n\n    Additionally various helper functions are provided that make working with\n    the trees simpler.  The main intention of the helper functions and this\n    module in general is to provide an easy to use interface for libraries\n    that work tightly with the pyth...(truncated), locals=0x0, 
    args=0x7fffea9321c8, argcount=1, kwnames=0x0, kwargs=0x7fffea9321d0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='literal_eval', qualname='literal_eval') at Python/ceval.c:4299
#21 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea7f7e10>, stack=0x7fffea9321c8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:395
#22 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea7f7e10>, args=0x7fffea9321c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#23 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea7f7e10>, args=0x7fffea9321c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#24 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff3578, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#25 0x00000000005193a1 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, f=Frame 0x7fffea932050, for file script.py, line 27, in <module> (), throwflag=0) at Python/ceval.c:3459
#26 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, f=Frame 0x7fffea932050, for file script.py, line 27, in <module> (), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#27 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), args=0x0, 
    argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
#28 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), args=0x0, 
    argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4331
#29 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), args=0x0, 
    argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#30 0x000000000050bbc0 in PyEval_EvalCode (co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated))
    at Python/ceval.c:809
#31 0x000000000069ce37 in builtin_exec_impl (module=<module at remote 0x7fffeabc3a10>, source=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated))
    at Python/bltinmodule.c:1035
#32 0x000000000069ac76 in builtin_exec (module=<module at remote 0x7fffeabc3a10>, args=0x9b3e60, nargs=2) at Python/clinic/bltinmodule.c.h:396
#33 0x00000000006551f4 in cfunction_vectorcall_FASTCALL (func=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0x9b3e60, nargsf=9223372036854775810, kwnames=0x0) at Objects/methodobject.c:424
#34 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0x9b3e60, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#35 0x0000000000509a90 in PyObject_Vectorcall (callable=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0x9b3e60, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#36 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff4f18, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#37 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x9b3ca0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffeaab9450>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all'...(truncated), throwflag=0)
    at Python/ceval.c:3490
#38 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x9b3ca0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffeaab9450>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all'...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#39 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaab9790>, 
    globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffeaa980a0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffeaa980f0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, 
    args=0x9b3c18, argcount=7, kwnames=0x0, kwargs=0x9b3c50, kwcount=0, kwstep=1, defs=0x7fffeaaaaed8, defcount=5, kwdefs=0x0, closure=0x0, name='_run_code', qualname='_run_code') at Python/ceval.c:4299
#40 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffeab9bd70>, stack=0x9b3c18, nargsf=9223372036854775815, kwnames=0x0) at Objects/call.c:395
#41 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffeab9bd70>, args=0x9b3c18, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:118
#42 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffeab9bd70>, args=0x9b3c18, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:127
#43 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff6738, oparg=7, kwnames=0x0) at Python/ceval.c:5044
#44 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x9b3a50, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffeaab9450>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='script.py', fname='script.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffea7f4f50>, _saved_module=[<module at remote 0x7fffeab12b90>]) at remote 0x7fffea917aa0>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) a...(truncated), throwflag=0)
    at Python/ceval.c:3490
#45 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x9b3a50, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffeaab9450>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='script.py', fname='script.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffea7f4f50>, _saved_module=[<module at remote 0x7fffeab12b90>]) at remote 0x7fffea917aa0>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) a...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#46 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaab9860>, 
    globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffeaa980a0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffeaa980f0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, 
    args=0x994310, argcount=3, kwnames=0x7fffeaa98568, kwargs=0x994328, kwcount=2, kwstep=1, defs=0x7fffeaab6928, defcount=5, kwdefs=0x0, closure=0x0, name='_run_module_code', qualname='_run_module_code') at Python/ceval.c:4299
#47 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e7af0>, stack=0x994310, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at Objects/call.c:395
#48 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea8e7af0>, args=0x994310, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at ./Include/cpython/abstract.h:118
#49 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea8e7af0>, args=0x994310, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at ./Include/cpython/abstract.h:127
#50 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff7f48, oparg=5, kwnames=('pkg_name', 'script_name')) at Python/ceval.c:5044
#51 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x994140, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='script.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffeaab9450>, fname='script.py'), throwflag=0) at Python/ceval.c:3507
#52 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x994140, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='script.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffeaab9450>, fname='script.py'), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#53 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaa9c040>, 
    globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffeaa980a0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffeaa980f0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, 
    args=0x969508, argcount=1, kwnames=0x7fffeabcd478, kwargs=0x969510, kwcount=1, kwstep=1, defs=0x7fffeaa98608, defcount=2, kwdefs=0x0, closure=0x0, name='run_path', qualname='run_path') at Python/ceval.c:4299
#54 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e7eb0>, stack=0x969508, nargsf=9223372036854775809, kwnames=('run_name',)) at Objects/call.c:395
#55 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea8e7eb0>, args=0x969508, nargsf=9223372036854775809, kwnames=('run_name',)) at ./Include/cpython/abstract.h:118
#56 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea8e7eb0>, args=0x969508, nargsf=9223372036854775809, kwnames=('run_name',)) at ./Include/cpython/abstract.h:127
#57 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff9768, oparg=2, kwnames=('run_name',)) at Python/ceval.c:5044
#58 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x969360, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 17, in smoke_test (script='script.py', args=(), old_argv=['./repro.py'], old_modules={'sys': <module at remote 0x7fffeabba2f0>, 'builtins': <module at remote 0x7fffeabc3a10>, '_frozen_importlib': <module at remote 0x7fffeab60a70>, '_imp': <module at remote 0x7fffeab60a10>, '_thread': <module at remote 0x7fffeab6e3b0>, '_warnings': <module at remote 0x7fffeab6ef50>, '_weakref': <module at remote 0x7fffeab6f350>, '_frozen_importlib_external': <module at remote 0x7fffeab6fcb0>, 'posix': <module at remote 0x7fffeab6fb30>, '_io': <module at remote 0x7fffeab33290>, 'marshal': <module at remote 0x7fffeab3bdd0>, 'time': <module at remote 0x7fffeab47290>, 'zipimport': <module at remote 0x7fffeab3d350>, '_codecs': <module at remote 0x7fffeaaeaa10>, 'codecs': <module at remote 0x7fffeab57710>, 'encodings.aliases': <module at remote 0x7fffeaaea5f0>, 'encodings': <module at remote 0x7fffeab4d830>, 'encodings.utf_8': <module at remo...(truncated), throwflag=0)
    at Python/ceval.c:3507
#59 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x969360, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 17, in smoke_test (script='script.py', args=(), old_argv=['./repro.py'], old_modules={'sys': <module at remote 0x7fffeabba2f0>, 'builtins': <module at remote 0x7fffeabc3a10>, '_frozen_importlib': <module at remote 0x7fffeab60a70>, '_imp': <module at remote 0x7fffeab60a10>, '_thread': <module at remote 0x7fffeab6e3b0>, '_warnings': <module at remote 0x7fffeab6ef50>, '_weakref': <module at remote 0x7fffeab6f350>, '_frozen_importlib_external': <module at remote 0x7fffeab6fcb0>, 'posix': <module at remote 0x7fffeab6fb30>, '_io': <module at remote 0x7fffeab33290>, 'marshal': <module at remote 0x7fffeab3bdd0>, 'time': <module at remote 0x7fffeab47290>, 'zipimport': <module at remote 0x7fffeab3d350>, '_codecs': <module at remote 0x7fffeaaeaa10>, 'codecs': <module at remote 0x7fffeab57710>, 'encodings.aliases': <module at remote 0x7fffeaaea5f0>, 'encodings': <module at remote 0x7fffeab4d830>, 'encodings.utf_8': <module at remo...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#60 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaaa2a00>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals=0x0, args=0x910810, argcount=1, kwnames=0x0, kwargs=0x910818, kwcount=0, kwstep=1, 
    defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='smoke_test', qualname='smoke_test') at Python/ceval.c:4299
#61 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffeaaa8190>, stack=0x910810, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:395
#62 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffeaaa8190>, args=0x910810, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#63 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffeaaa8190>, args=0x910810, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#64 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffffaf98, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#65 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, f=Frame 0x9106a0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 35, in <module> (), throwflag=0) at Python/ceval.c:3490
#66 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, f=Frame 0x9106a0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 35, in <module> (), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#67 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaaa2d40>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, 
    locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, 
    kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
--Type <RET> for more, q to quit, c to continue without paging--c
#68 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fffeaaa2d40>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4331
#69 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=<code at remote 0x7fffeaaa2d40>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#70 0x000000000050bbc0 in PyEval_EvalCode (co=<code at remote 0x7fffeaaa2d40>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}) at Python/ceval.c:809
#71 0x000000000056eaf9 in run_eval_code_obj (tstate=0x8b19a0, co=0x7fffeaaa2d40, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}) at Python/pythonrun.c:1178
#72 0x000000000056ebe2 in run_mod (mod=0x93a0d8, filename='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, flags=0x7fffffffc9a8, arena=0x7fffeaaa7b20) at Python/pythonrun.c:1199
#73 0x000000000056e971 in PyRun_FileExFlags (fp=0x8aebf0, filename_str=0x7fffeaa837e0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", start=257, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, closeit=1, flags=0x7fffffffc9a8) at Python/pythonrun.c:1116
#74 0x000000000056d447 in PyRun_SimpleFileExFlags (fp=0x8aebf0, filename=0x7fffeaa837e0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", closeit=1, flags=0x7fffffffc9a8) at Python/pythonrun.c:438
#75 0x000000000056c958 in PyRun_AnyFileExFlags (fp=0x8aebf0, filename=0x7fffeaa837e0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", closeit=1, flags=0x7fffffffc9a8) at Python/pythonrun.c:87
#76 0x000000000041e6e8 in pymain_run_file (config=0x8b0470, cf=0x7fffffffc9a8) at Modules/main.c:369
#77 0x000000000041ecd8 in pymain_run_python (exitcode=0x7fffffffc9ec) at Modules/main.c:594
#78 0x000000000041edc9 in Py_RunMain () at Modules/main.c:673
#79 0x000000000041ee43 in pymain_main (args=0x7fffffffca50) at Modules/main.c:703
#80 0x000000000041eebd in Py_BytesMain (argc=2, argv=0x7fffffffcb88) at Modules/main.c:727
#81 0x000000000041d786 in main (argc=2, argv=0x7fffffffcb88) at ./Programs/python.c:15
(gdb) py
py-bt               py-down             py-locals           py-up               pyframev            pylocals            pystack             python              
py-bt-full          py-list             py-print            pyframe             pyg                 pyo                 pystackv            python-interactive  
(gdb) py-bt-full
#7 <built-in method compile of module object at remote 0x7fffeabc3a10>
#11 Frame 0x9c8850, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated)
    lines.append(next_line)
#18 Frame 0x7fffea816050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated)
    node_or_string = parse(node_or_string, mode='eval')
#25 Frame 0x7fffea932050, for file script.py, line 27, in <module> ()
    python_info = ast.literal_eval(result)
#33 <built-in method exec of module object at remote 0x7fffeabc3a10>
#37 Frame 0x9b3ca0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffeaab9450>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all'...(truncated)
#44 Frame 0x9b3a50, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffeaab9450>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='script.py', fname='script.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffea7f4f50>, _saved_module=[<module at remote 0x7fffeab12b90>]) at remote 0x7fffea917aa0>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) a...(truncated)
#51 Frame 0x994140, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='script.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffeaab9450>, fname='script.py')
#58 Frame 0x969360, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 17, in smoke_test (script='script.py', args=(), old_argv=['./repro.py'], old_modules={'sys': <module at remote 0x7fffeabba2f0>, 'builtins': <module at remote 0x7fffeabc3a10>, '_frozen_importlib': <module at remote 0x7fffeab60a70>, '_imp': <module at remote 0x7fffeab60a10>, '_thread': <module at remote 0x7fffeab6e3b0>, '_warnings': <module at remote 0x7fffeab6ef50>, '_weakref': <module at remote 0x7fffeab6f350>, '_frozen_importlib_external': <module at remote 0x7fffeab6fcb0>, 'posix': <module at remote 0x7fffeab6fb30>, '_io': <module at remote 0x7fffeab33290>, 'marshal': <module at remote 0x7fffeab3bdd0>, 'time': <module at remote 0x7fffeab47290>, 'zipimport': <module at remote 0x7fffeab3d350>, '_codecs': <module at remote 0x7fffeaaeaa10>, 'codecs': <module at remote 0x7fffeab57710>, 'encodings.aliases': <module at remote 0x7fffeaaea5f0>, 'encodings': <module at remote 0x7fffeab4d830>, 'encodings.utf_8': <module at remo...(truncated)
    return run_path(script, run_name="__main__")
#65 Frame 0x9106a0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 35, in <module> ()
    smoke_test("script.py")
(gdb) py-bt
Traceback (most recent call first):
  <built-in method compile of module object at remote 0x7fffeabc3a10>
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py", line 306, in parse
    lines.append(next_line)
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py", line 62, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "script.py", line 27, in <module>
    python_info = ast.literal_eval(result)
  <built-in method exec of module object at remote 0x7fffeabc3a10>
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 343, in _run_code
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 353, in _run_module_code
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 524, in run_path
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", line 17, in smoke_test
    return run_path(script, run_name="__main__")
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", line 35, in <module>
    smoke_test("script.py")
(gdb)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:21:48 2020
From: report at bugs.python.org (Andy Lester)
Date: Wed, 08 Jul 2020 22:21:48 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1594246908.78.0.8963718434.issue40170@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy:  -petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:47:37 2020
From: report at bugs.python.org (Marco Paolini)
Date: Wed, 08 Jul 2020 22:47:37 +0000
Subject: [issue34624] -W option and PYTHONWARNINGS env variable does not
 accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1594248457.96.0.0868280392917.issue34624@roundup.psfhosted.org>


Marco Paolini <markopaolini at gmail.com> added the comment:

hello Thomas,

do you need any help fixing the conflicts in your PR?


even if Lib/warnings.py changed a little in the last 2 years, your PR is still good!

----------
nosy: +mpaolini

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Wed Jul  8 19:05:37 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 08 Jul 2020 23:05:37 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1594249537.61.0.469640059192.issue37179@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Looks like https://github.com/python/cpython/pull/17975 was forgotten and was never committed to 3.9. So it's 3.10 now.

Best bet for you is to use uvloop which should support the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Wed Jul  8 19:08:33 2020
From: report at bugs.python.org (Cooper Lees)
Date: Wed, 08 Jul 2020 23:08:33 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1594249713.75.0.0713470146528.issue37179@roundup.psfhosted.org>


Change by Cooper Lees <me at cooperlees.com>:


----------
keywords: +patch
pull_requests: +20556
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17975

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Wed Jul  8 19:47:38 2020
From: report at bugs.python.org (Keith Blaha)
Date: Wed, 08 Jul 2020 23:47:38 +0000
Subject: [issue41249] TypedDict inheritance doesn't work with get_type_hints
 and postponed evaluation of annotations across modules
Message-ID: <1594252058.32.0.479050209218.issue41249@roundup.psfhosted.org>


New submission from Keith Blaha <keith.blaha at gmail.com>:

Copied from https://github.com/python/typing/issues/737

I came across this issue while using inheritance to express required keys in a TypedDict, as is recommended by the docs.

It's most easily explained by a minimal example I cooked up. Let's say we have a module foo.py:

from __future__ import annotations

from typing import Optional
from typing_extensions import TypedDict

class Foo(TypedDict):
    a: Optional[int]

And another module bar.py:

from __future__ import annotations

from typing import get_type_hints
from foo import Foo

class Bar(Foo, total=False):
    b: int

print(get_type_hints(Bar))

Note that both foo.py and bar.py have adopted postponed evaluation of annotations (PEP 563) by using the __future__ import.

If we execute bar.py, we get the error message NameError: name 'Optional' is not defined.

This is due to the combination of:

    get_type_hints relies on the MRO to resolve types: https://github.com/python/cpython/blob/3.7/Lib/typing.py#L970
    TypedDict does not preserve the original bases, so Foo is not in the MRO for Bar:

    typing/typing_extensions/src_py3/typing_extensions.py

    Line 1652 in d79edde

     tp_dict = super(_TypedDictMeta, cls).__new__(cls, name, (dict,), ns) 

Thus, get_type_hints is unable to resolve the types for annotations that are only imported in foo.py.

I ran this example using typing_extensions 3.7.4.2 (released via #709) and Python 3.7.3, but it seems like this would be an issue using the current main branches of both repositories as well.

I'm wondering what the right approach is to tackling this issue. It is of course solvable by defining Bar in foo.py instead, but it isn't ideal or intuitive to always need to inherit from a TypedDict in the same module.

I was thinking that similarly to __required_keys__ and __optional_keys__, the TypedDict could preserve its original bases in a new dunder attribute, and get_type_hints could work off of that instead of MRO when it is dealing with a TypedDict. I would be willing to contribute the PRs to implement this if the design is acceptable, but am open to other ideas as well.

----------
components: Library (Lib)
messages: 373360
nosy: keithblaha
priority: normal
severity: normal
status: open
title: TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
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/issue41249>
_______________________________________

From report at bugs.python.org  Wed Jul  8 19:51:53 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 08 Jul 2020 23:51:53 +0000
Subject: [issue41249] TypedDict inheritance doesn't work with get_type_hints
 and postponed evaluation of annotations across modules
In-Reply-To: <1594252058.32.0.479050209218.issue41249@roundup.psfhosted.org>
Message-ID: <1594252313.34.0.632217943315.issue41249@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41249>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:13:38 2020
From: report at bugs.python.org (Abhilash Raj)
Date: Thu, 09 Jul 2020 00:13:38 +0000
Subject: [issue41206] behaviour change with EmailMessage.set_content
In-Reply-To: <1593818098.6.0.402799066413.issue41206@roundup.psfhosted.org>
Message-ID: <1594253618.49.0.240265184102.issue41206@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

I have merged https://github.com/python/cpython/pull/20542 and backported to 3.8 and 3.9 branches (https://github.com/python/cpython/pull/21404 & https://github.com/python/cpython/pull/21405).

Closing this issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41206>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:18:35 2020
From: report at bugs.python.org (Abhilash Raj)
Date: Thu, 09 Jul 2020 00:18:35 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594253915.27.0.974540820879.issue40597@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Closing this since the PRs for the behavior change reported by Mike and BPO-41206 is now merged too.

----------
nosy: +maxking
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:19:01 2020
From: report at bugs.python.org (Abhilash Raj)
Date: Thu, 09 Jul 2020 00:19:01 +0000
Subject: [issue40597] generated email message exceeds RFC-mandated limit of
 998 characters
In-Reply-To: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>
Message-ID: <1594253941.14.0.540680143913.issue40597@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Thanks Mark!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40597>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:19:43 2020
From: report at bugs.python.org (Cooper Lees)
Date: Thu, 09 Jul 2020 00:19:43 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1594253983.86.0.476856477953.issue37179@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

Yury, only problem with that is aiohttp hard blocks HTTPS proxies period. The aiohttp issue says they won't fix this until asyncio supports it. Kinda understand that.

[cooper:~]$ ./aioclient.par
HTTPS proxies https://fwdproxy:8082 are not supported, ignoring
^CTraceback (most recent call last):
  File "<string>", line 37, in <module>
  File "<string>", line 35, in __run
  File "/usr/local/fbcode/platform007/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/fbcode/platform007/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/data/users/cooper/fbsource/fbcode/buck-out/dev/gen/ti/fwdproxy/client_samples/py/aioclient#link-tree/ti/fwdproxy/client_samples/py/aioclient.py", line 56, in <module>
    asyncio.run(run_example())
  File "/usr/local/fbcode/platform007/lib/python3.7/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "uvloop/loop.pyx", line 1450, in uvloop.loop.Loop.run_until_complete
  File "uvloop/loop.pyx", line 1443, in uvloop.loop.Loop.run_until_complete
  File "uvloop/loop.pyx", line 1351, in uvloop.loop.Loop.run_forever
  File "uvloop/loop.pyx", line 519, in uvloop.loop.Loop._run
  File "uvloop/handles/poll.pyx", line 213, in uvloop.loop.__on_uvpoll_event
  File "uvloop/cbhandles.pyx", line 90, in uvloop.loop.Handle._run
  File "uvloop/cbhandles.pyx", line 73, in uvloop.loop.Handle._run
  File "uvloop/loop.pyx", line 359, in uvloop.loop.Loop._read_from_self
  File "uvloop/loop.pyx", line 364, in uvloop.loop.Loop._invoke_signals
  File "uvloop/loop.pyx", line 339, in uvloop.loop.Loop._ceval_process_signals
KeyboardInterrupt

Kept stack trace to prove I was using uvloop :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:24:30 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2020 00:24:30 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594254270.25.0.212688259374.issue37765@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tal, I suggested the compromise because of your original objection.  Since you think half is worse than all, I will revert the change.  It did get me to do a needed rewrite of the Completions section of the IDLE doc.

----------
title: IDLE: Include longer keywords in __main__ autocomplete list -> IDLE: Include keywords in module-level autocomplete list

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:08:06 2020
From: report at bugs.python.org (Wu Wenyan)
Date: Thu, 09 Jul 2020 01:08:06 +0000
Subject: [issue41239] SSL Certificate verify failed in Python3.6/3.7
In-Reply-To: <1594196827.07.0.525531183608.issue41239@roundup.psfhosted.org>
Message-ID: <1594256886.58.0.67655353674.issue41239@roundup.psfhosted.org>


Wu Wenyan <wuwy.fnst at cn.fujitsu.com> added the comment:

OK. Thanks for your suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41239>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:30:21 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 09 Jul 2020 01:30:21 +0000
Subject: [issue41250] Number separators in different places
Message-ID: <1594258221.41.0.149493736122.issue41250@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

The current syntax is this for thousand separators:
f'{var:,}'
It will return this when var is 1234567:
'1,234,567'
But sometimes we need a way to insert them in other places. For example:
123456789 ? '1,2345,6789' (4)
62938757312 ? '6,29387,57312' (5)
This could be done like this:
Idea 1:
Add a new method to string:
string.sep(num: int_or_float, interval: int_or_iterable = 3, 
           sepchar: str = ',')
>>> import string
>>> string.sep(1234567, 3)
'1,234,567'
>>> string.sep(1234567890, range(1, 4))
'1,23,456,7890'
>>> string.sep('Hello')
TypeError: Invalid number 'Hello'
>>> string.sep(12345678, sepchar=' ')
'12 345 678'
>>> string.sep(123456789, 4, '|')
'1|2345|6789'

Idea 2: (Not as powerful as above)
(Future)
>>> f'{123456789:4,}'
'1,2345,6789'
>>> f'{62938757312:5,}'
'6,29387,57312'
>>> f'{1234567:,}' # Equal to f'{1234567:3,}'
'1,234,567'
(Current)
>>> f'{12345678:5,}' # 5 discarded
'12,345,678'

----------
components: Interpreter Core, Library (Lib)
messages: 373367
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Number separators in different places
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41250>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:45:21 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 09 Jul 2020 01:45:21 +0000
Subject: [issue41250] Number separators in different places
In-Reply-To: <1594258221.41.0.149493736122.issue41250@roundup.psfhosted.org>
Message-ID: <1594259121.75.0.984592591069.issue41250@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Q: Why not use f"{var:,}".replace(',', sepchar) for the sepchar parameter?
A: It is very complicated in the case below:
num = 1234567
text = 'Hello, world!'
print(f"{num:,}{text}").replace(',', ' ') # Becomes '1 234 567Hello world!'
print(f"{f'{num:,}'.replace(',', ' ')}{text}") # Too complicated!
print(f"{num:,}".replace(',', ' ')+text) # Slow!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41250>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:59:15 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 09 Jul 2020 01:59:15 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
Message-ID: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

__future__.barry_as_FLUFL turns x!=y into x<>y.
But the doc by help() says:
Help on _Feature in module __future__ object:                                                                                                                                                                                                               class _Feature(builtins.object)
--snip--
|  getMandatoryRelease(self)                                                                                                  |      Return release in which this feature will become mandatory.                                                            |                                                                                                                             |      This is a 5-tuple, of the same form as sys.version_info, or, if                                                        |      the feature was dropped, is None. 
--snip--

Since <> is dropped, __future__.barry_as_FLUFL.getMandatoryRelease() should be None. But it instead returns (4, 0, 0, 'alpha', 0), which
means it will become default in Python 4 and drop != (!= is invalid
after the __future__ import).
That shouldn't be right.

----------
messages: 373369
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: __future__.barry_as_FLUFL.getMandatoryRelease() is wrong

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:59:40 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 09 Jul 2020 01:59:40 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
In-Reply-To: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>
Message-ID: <1594259980.91.0.298475321979.issue41251@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
components: +Library (Lib)
versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Wed Jul  8 22:01:02 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 09 Jul 2020 02:01:02 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
In-Reply-To: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>
Message-ID: <1594260062.39.0.149745923894.issue41251@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Help on _Feature in module __future__ object:                                                                                                                                                                                                               class _Feature(builtins.object)
--snip--
|  getMandatoryRelease(self)
|      Return release in which this feature will become mandatory.
|
|      This is a 5-tuple, of the same form as sys.version_info, or, if
|     the feature was dropped, is None. 
--snip--

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Wed Jul  8 22:02:46 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 09 Jul 2020 02:02:46 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
In-Reply-To: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>
Message-ID: <1594260166.38.0.529675278609.issue41251@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Wed Jul  8 23:53:04 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 09 Jul 2020 03:53:04 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
Message-ID: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

In _servername_callback(), servername_bytes will be used after being
decrefed if PyUnicode_FromEncodedObject() fails.

----------
assignee: christian.heimes
components: Extension Modules, SSL
messages: 373371
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: Incorrect reference counting in _ssl.c's _servername_callback()
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Wed Jul  8 23:56:24 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 09 Jul 2020 03:56:24 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594266984.79.0.888333505152.issue41252@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +20557
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21407

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Wed Jul  8 23:58:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jul 2020 03:58:45 +0000
Subject: [issue41250] Number separators in different places
In-Reply-To: <1594258221.41.0.149493736122.issue41250@roundup.psfhosted.org>
Message-ID: <1594267125.71.0.841306256603.issue41250@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41250>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:37:30 2020
From: report at bugs.python.org (Faris Chugthai)
Date: Thu, 09 Jul 2020 04:37:30 +0000
Subject: [issue41253] unittest -h shows a flag -s but it doesn't work
Message-ID: <1594269450.68.0.624090697882.issue41253@roundup.psfhosted.org>


New submission from Faris Chugthai <farischugthai at gmail.com>:

I'm not 100% sure what's happening here but running:

`python -m unittest -h`

shows a flag `-s` as does

`python -m unittest discover -h`.

When run as:

`python -m unittest discover -s test`

the command runs correctly but when run as

`python -m unittest -s test`

the command fails.

```sh

$ python -m unittest -s test  
                      
usage: python -m unittest [-h] [-v] [-q] [--locals] [-f]                                [-c] [-b] [-k TESTNAMEPATTERNS]                               [tests [tests ...]

       
python -m unittest: error: unrecognized arguments: -s

```

Which I believe to be a bug as the help generated by the discover subcommand indicates that the flag -s should be recognized.

----------
components: Tests
messages: 373372
nosy: Faris Chugthai
priority: normal
severity: normal
status: open
title: unittest -h shows a flag -s but it doesn't work
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41253>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:47:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jul 2020 04:47:22 +0000
Subject: [issue41253] unittest -h shows a flag -s but it doesn't work
In-Reply-To: <1594269450.68.0.624090697882.issue41253@roundup.psfhosted.org>
Message-ID: <1594270042.25.0.917125374308.issue41253@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Where do you see option -s?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41253>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:55:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jul 2020 04:55:17 +0000
Subject: [issue41250] Number separators in different places
In-Reply-To: <1594258221.41.0.149493736122.issue41250@roundup.psfhosted.org>
Message-ID: <1594270517.89.0.355045036862.issue41250@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This was considered in PEP 378 ? Format Specifier for Thousands Separator.?  The decision was to keep it simple and only support groups of three digits using a comma as the separator.

FWIW, the decimal documentation has a formatting recipe that could be adapted to meet your needs.?

? https://www.python.org/dev/peps/pep-0378/
? https://docs.python.org/3/library/decimal.html#recipes

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41250>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:59:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jul 2020 04:59:56 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
In-Reply-To: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>
Message-ID: <1594270796.1.0.0818608216724.issue41251@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was not officially dropped. It was kept as a joke.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:05:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jul 2020 05:05:09 +0000
Subject: [issue41253] unittest -h shows a flag -s but it doesn't work
In-Reply-To: <1594269450.68.0.624090697882.issue41253@roundup.psfhosted.org>
Message-ID: <1594271109.41.0.261375169298.issue41253@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The -s option shown in `python3 -m unittest -h` is grouped under help for discover. Options for a discover command don't necessarily apply to the unittest command itself.

$ python3 -m unittest -h
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
                           [-k TESTNAMEPATTERNS]
                           [tests [tests ...]]

positional arguments:
  tests                a list of any number of test modules, classes and test
                       methods.

optional arguments:
  -h, --help           show this help message and exit
  -v, --verbose        Verbose output
  -q, --quiet          Quiet output
  --locals             Show local variables in tracebacks
  -f, --failfast       Stop on first fail or error
  -c, --catch          Catch Ctrl-C and display results so far
  -b, --buffer         Buffer stdout and stderr during tests
  -k TESTNAMEPATTERNS  Only run tests which match the given substring

Examples:
  python3 -m unittest test_module               - run tests from test_module
  python3 -m unittest module.TestClass          - run tests from module.TestClass
  python3 -m unittest module.Class.test_method  - run specified test method
  python3 -m unittest path/to/test_file.py      - run tests from test_file.py

usage: python3 -m unittest discover [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
                                    [-k TESTNAMEPATTERNS] [-s START]
                                    [-p PATTERN] [-t TOP]

optional arguments:
  -h, --help            show this help message and exit
  -v, --verbose         Verbose output
  -q, --quiet           Quiet output
  --locals              Show local variables in tracebacks
  -f, --failfast        Stop on first fail or error
  -c, --catch           Catch Ctrl-C and display results so far
  -b, --buffer          Buffer stdout and stderr during tests
  -k TESTNAMEPATTERNS   Only run tests which match the given substring
  -s START, --start-directory START
                        Directory to start discovery ('.' default)
  -p PATTERN, --pattern PATTERN
                        Pattern to match tests ('test*.py' default)
  -t TOP, --top-level-directory TOP
                        Top level directory of project (defaults to start
                        directory)

For test discovery all test modules must be importable from the top level
directory of the project.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41253>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:39:29 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Thu, 09 Jul 2020 05:39:29 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594273169.59.0.128161123557.issue41199@roundup.psfhosted.org>


Wansoo Kim <rladhkstn8 at gmail.com> added the comment:

May I solve this issue?

----------
nosy: +ys19991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:50:04 2020
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Thu, 09 Jul 2020 05:50:04 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594273804.83.0.558375506783.issue41199@roundup.psfhosted.org>


Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com> added the comment:

Please go ahead and create a PR.

----------
nosy: +thatiparthy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 02:29:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Jul 2020 06:29:06 +0000
Subject: [issue41250] Number separators in different places
In-Reply-To: <1594258221.41.0.149493736122.issue41250@roundup.psfhosted.org>
Message-ID: <1594276146.41.0.416591989361.issue41250@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The formatting specification language is already complicated enough without adding even more to it. As PEP 378 says "It is not the goal to replace the locale module, to perform internationalization tasks, or accommodate every possible convention."

Your best bet is to write your own formater and use that:

f'{formater(v)}'

You could also pass it whatever parameters you want, like specifying the number of digits or the separator or whether to use the locale to determine these things.

The PEP suggests Babel (http://babel.pocoo.org/en/latest/), which I don't have any experience with, but seems pretty complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41250>
_______________________________________

From report at bugs.python.org  Thu Jul  9 02:46:58 2020
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 09 Jul 2020 06:46:58 +0000
Subject: [issue41254] Add to/from string methods to datetime.timedelta
Message-ID: <1594277218.28.0.16887324914.issue41254@roundup.psfhosted.org>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

I suggest adding datetime.timedelta methods that convert to/from str.

The reason is that I have several places where configuration contains various timeouts. I'd like to write '50ms' and not 0.05 which is more human readable.

See https://golang.org/pkg/time/#ParseDuration for how Go does it.

----------
components: Library (Lib)
messages: 373380
nosy: tebeka
priority: normal
severity: normal
status: open
title: Add to/from string methods to datetime.timedelta
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41254>
_______________________________________

From report at bugs.python.org  Thu Jul  9 03:10:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jul 2020 07:10:44 +0000
Subject: [issue41254] Add to/from string methods to datetime.timedelta
In-Reply-To: <1594277218.28.0.16887324914.issue41254@roundup.psfhosted.org>
Message-ID: <1594278644.95.0.728630268309.issue41254@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41254>
_______________________________________

From report at bugs.python.org  Thu Jul  9 03:30:00 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Jul 2020 07:30:00 +0000
Subject: [issue41254] Add to/from string methods to datetime.timedelta
In-Reply-To: <1594277218.28.0.16887324914.issue41254@roundup.psfhosted.org>
Message-ID: <1594279800.23.0.508757321895.issue41254@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41254>
_______________________________________

From report at bugs.python.org  Thu Jul  9 04:25:17 2020
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 09 Jul 2020 08:25:17 +0000
Subject: [issue41237] Access violation in python39.dll!meth_dealloc on exit
In-Reply-To: <1594188565.24.0.738467793313.issue41237@roundup.psfhosted.org>
Message-ID: <1594283117.62.0.312560395264.issue41237@roundup.psfhosted.org>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

This issue seems specific to C extensions built with pybind11 (using 2.5.0 and master branch). Building the minimal example at https://github.com/pybind/python_example and running `python.exe -c"import python_example"` will crash at exit.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41237>
_______________________________________

From report at bugs.python.org  Thu Jul  9 04:40:33 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Thu, 09 Jul 2020 08:40:33 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
Message-ID: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>


New submission from Matthew Hughes <matthewhughes934 at gmail.com>:

>>> import argparse
    >>> parser = argparse.ArgumentParser(exit_on_error=False)
    >>> parser.parse_args(["--unknown"])
    usage: [-h]
    : error: unrecognized arguments: --unknown

The docs https://docs.python.org/3.10/library/argparse.html#exit-on-error say:

> Normally, when you pass an invalid argument list to the parse_args() method of an ArgumentParser, it will exit with error info.
> If the user would like catch errors manually, the feature can be enable by setting exit_on_error to False:

This description _appears_ to be at odds with the observed behavior.

----------
components: Library (Lib)
messages: 373382
nosy: mhughes
priority: normal
severity: normal
status: open
title: Argparse.parse_args exits on unrecognized option with exit_on_error=False
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:05:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jul 2020 09:05:01 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
In-Reply-To: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>
Message-ID: <1594285501.37.0.423339095787.issue41255@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess the docs by manually mean that ArgumentError will be raised when exit_on_error is False that can be handled. By default with exit_on_error being True self.error() which raises SystemExit and catching SystemExit can mask other errors. This was added in bpo-9938 with GH-15362. There is also a typo in the docs that it should have used enabled instead of enable in "the feature can be enable by setting exit_on_error to False"

----------
nosy: +paul.j3, rhettinger, xtreak
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:28:29 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 09 Jul 2020 09:28:29 +0000
Subject: [issue12800] 'tarfile.StreamError: seeking backwards is not allowed'
 when extract symlink
In-Reply-To: <1313881060.54.0.449889075101.issue12800@psf.upfronthosting.co.za>
Message-ID: <1594286909.45.0.297804512283.issue12800@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +20558
pull_request: https://github.com/python/cpython/pull/21409

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12800>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:29:15 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 09 Jul 2020 09:29:15 +0000
Subject: [issue12800] 'tarfile.StreamError: seeking backwards is not allowed'
 when extract symlink
In-Reply-To: <1313881060.54.0.449889075101.issue12800@psf.upfronthosting.co.za>
Message-ID: <1594286955.27.0.818296180474.issue12800@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Strange fact, this was already fixed in 011525ee92eb1c13ad1a62d28725a840e28f8160 (which closes issue10761, nice spot Andrew) but was lost during a merge in 0d28a61d23:

$ git show 0d28a61d23
commit 0d28a61d233c02c458c8b4a25613be2f4979331e
Merge: ed3a303548 d7c9d9cdcd

$ git show 0d28a61d23:Lib/tarfile.py | grep unlink  # The merge commit does no longer contains the fix

$ git show ed3a303548:Lib/tarfile.py | grep unlink  # The "left" parent does not contains it neither

$ git show d7c9d9cdcd:Lib/tarfile.py | grep unlink  # The "right" one does contains it.
                    os.unlink(targetpath)
                        os.unlink(targetpath)

Stranger fact, the test was not lost during the merge, and still lives today (test_extractall_symlinks).

Happen that the current test is passing because it's in part erroneous, instead of trying to create a symlink on an existing one, it creates a symlink far far away:

(Pdb) p targetpath
'/home/mdk/clones/python/cpython/@test_648875_tmp-tardir/testsymlinks/home/mdk/clones/python/cpython/@test_648875_tmp-tardir/testsymlinks/symlink'

Aditionally it passes anway because tar.errorlevel equals 1, which means the error is logged but not raised.

With the following small patch:

--- a/Lib/test/test_tarfile.py
+++ b/Lib/test/test_tarfile.py
@@ -1339,10 +1339,10 @@ class WriteTest(WriteTestBase, unittest.TestCase):
                 f.write('something\n')
             os.symlink(source_file, target_file)
             with tarfile.open(temparchive, 'w') as tar:
-                tar.add(source_file)
-                tar.add(target_file)
+                tar.add(source_file, arcname="source")
+                tar.add(target_file, arcname="symlink")
             # Let's extract it to the location which contains the symlink
-            with tarfile.open(temparchive) as tar:
+            with tarfile.open(temparchive, errorlevel=2) as tar:
                 # this should not raise OSError: [Errno 17] File exists
                 try:
                     tar.extractall(path=tempdir)


the error is raised as expected: FileExistsError: [Errno 17] File exists: '/home/mdk/clones/python/cpython/@test_649794_tmp?-tardir/testsymlinks/source' -> '/home/mdk/clones/python/cpython/@test_649794_tmp?-tardir/testsymlinks/symlink'

I'm opening an PR to restore this as it was intended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12800>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:51:16 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Thu, 09 Jul 2020 09:51:16 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
In-Reply-To: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>
Message-ID: <1594288276.27.0.320570790725.issue41255@roundup.psfhosted.org>


Matthew Hughes <matthewhughes934 at gmail.com> added the comment:

> typo in the docs that it should have used enabled instead of enable

Well spotted, I'll happily fix this up.

> I guess the docs by manually mean that ArgumentError will be raised when exit_on_error is False that can be handled.

To be clear, in this case, even with exit_on_error=False, ArgumentError is _not_ being raised, but SystemExit is.

----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:57:08 2020
From: report at bugs.python.org (kunaltyagi)
Date: Thu, 09 Jul 2020 09:57:08 +0000
Subject: [issue41256] activate script created by venv is not smart enough
Message-ID: <1594288628.21.0.90149093497.issue41256@roundup.psfhosted.org>


New submission from kunaltyagi <kunal.tyagi.3.1994 at gmail.com>:

TLDR: `activate` script should be able to:
* inform user if it has been run and not sourced
* act as a placeholder to detect the shell being used and source the necessary `activate.{SHELL}` instead of throwing an error

---
It's mildly infuriating that `activate` on different setups needs to be called differently. The lack of messages when it's not sourced is also beginner unfriendly.

Both the issues are relatively easy to fix. First, making it shell agnostic. We can move the contents of `activate` to `activate.sh` and change `activate` to contain code like:
```sh
[ $FISH_VERSION ] && . activate.fish
[ $BASH_VERSION ] && . activate.sh
...
```

This of course will fail hard when you try to `. <venv_location>/bin/activate`. Finding the path of the file is not trivial, but doable. If we assume `dirname` is not present on the system, we can use `<full_path>/activate.<SHELL>`.

Making the "sourced or ran" logic shell agnostic is slightly easier to accomplish due to `$_`, `$0`, `$BASH_SOURCE`.

It'll possibly take a non-trivial amount of code to accomplish something this trivial, but it'll save people with custom shells 3 keystrokes and make the workflow smoother.

----------
components: Library (Lib)
messages: 373386
nosy: kunaltyagi
priority: normal
severity: normal
status: open
title: activate script created by venv is not smart enough
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/issue41256>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:59:07 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 09 Jul 2020 09:59:07 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
In-Reply-To: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>
Message-ID: <1594288747.8.0.422870132905.issue41251@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's an easter egg and internal joke. Barry would be disapointed if we would deprive him of his title.

----------
nosy: +barry, christian.heimes
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:00:00 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 09 Jul 2020 10:00:00 +0000
Subject: [issue40941] Merge generator.gi_running and frame executing flag into
 single frame state
In-Reply-To: <1591795992.13.0.468529987519.issue40941@roundup.psfhosted.org>
Message-ID: <1594288800.02.0.964127164274.issue40941@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Mark, I want to flag issue29590 for you ("Incorrect stack traces when re-entering a generator/coroutine stack via .throw()") in case this issue relates to or would help at all with that.

----------
nosy: +chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40941>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:00:29 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 10:00:29 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594288829.59.0.620361028302.issue41252@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ee96f32ca24779656d3c8736d26671fc3689f0a3 by Zackery Spytz in branch 'master':
bpo-41252: Fix incorrect refcounting in _ssl.c's _servername_callback() (GH-21407)
https://github.com/python/cpython/commit/ee96f32ca24779656d3c8736d26671fc3689f0a3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:00:50 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 10:00:50 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594288850.64.0.476512410054.issue41252@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20560
pull_request: https://github.com/python/cpython/pull/21411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:00:42 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 10:00:42 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594288842.17.0.886822953309.issue41252@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20559
pull_request: https://github.com/python/cpython/pull/21410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:08:04 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jul 2020 10:08:04 +0000
Subject: [issue41256] activate script created by venv is not smart enough
In-Reply-To: <1594288628.21.0.90149093497.issue41256@roundup.psfhosted.org>
Message-ID: <1594289284.17.0.351783018867.issue41256@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41256>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:10:42 2020
From: report at bugs.python.org (tomaszdrozdz)
Date: Thu, 09 Jul 2020 10:10:42 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594289442.21.0.386771819197.issue41202@roundup.psfhosted.org>


tomaszdrozdz <tomasz.drozdz.1 at protonmail.com> added the comment:

OK.  
I understand.  

So how about maybe:  

    def run(main, *, debug=False, loop=None):  
        ...  
    
        if loop:  
            loop = events.new_event_loop()

So we could customize loop like:  

    loop = events.new_event_loop()  
    loop.set_XXX(...)  
    asyncio.run(my_coro, loop=loop)  

Just what tehn with debug parameter ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:15:40 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 10:15:40 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594289740.14.0.166632253975.issue41252@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 54babbe976531d4d1c21ea415f71e7c6846e15bc by Miss Islington (bot) in branch '3.8':
bpo-41252: Fix incorrect refcounting in _ssl.c's _servername_callback() (GH-21407)
https://github.com/python/cpython/commit/54babbe976531d4d1c21ea415f71e7c6846e15bc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:18:33 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 10:18:33 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594289913.59.0.192846248214.issue41252@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 90584c02b4dcfc087bee5e4131b7ba72b669d58a by Miss Islington (bot) in branch '3.9':
bpo-41252: Fix incorrect refcounting in _ssl.c's _servername_callback() (GH-21407)
https://github.com/python/cpython/commit/90584c02b4dcfc087bee5e4131b7ba72b669d58a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Thu Jul  9 06:27:55 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 09 Jul 2020 10:27:55 +0000
Subject: [issue41252] Incorrect reference counting in _ssl.c's
 _servername_callback()
In-Reply-To: <1594266784.28.0.798839997492.issue41252@roundup.psfhosted.org>
Message-ID: <1594290475.38.0.662454525519.issue41252@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41252>
_______________________________________

From report at bugs.python.org  Thu Jul  9 07:13:29 2020
From: report at bugs.python.org (daniel hahler)
Date: Thu, 09 Jul 2020 11:13:29 +0000
Subject: [issue41033] readline.c: SEGFAULT on SIGWINCH when loaded twice
In-Reply-To: <1592559834.18.0.183747914407.issue41033@roundup.psfhosted.org>
Message-ID: <1594293209.35.0.909206109986.issue41033@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

91e1bc18bd (bpo-41194) reminded me of this.
Maybe the same mechanism could be used here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41033>
_______________________________________

From report at bugs.python.org  Thu Jul  9 07:17:50 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 09 Jul 2020 11:17:50 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594293470.57.0.419723457522.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20561
pull_request: https://github.com/python/cpython/pull/21412

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Thu Jul  9 07:18:02 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Thu, 09 Jul 2020 11:18:02 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594293482.78.0.333766644805.issue41199@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
pull_requests: +20562
pull_request: https://github.com/python/cpython/pull/21413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:14:13 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 12:14:13 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594296853.46.0.950960007337.issue41199@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20563
pull_request: https://github.com/python/cpython/pull/21414

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:13:51 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 12:13:51 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594296831.38.0.779793738043.issue41199@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 61bb24a270d15106decb1c7983bf4c2831671a75 by marload in branch 'master':
bpo-41199: Docstring convention not followed for dataclasses documentation page (GH-21413)
https://github.com/python/cpython/commit/61bb24a270d15106decb1c7983bf4c2831671a75


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:14:23 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 12:14:23 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594296863.3.0.259373788295.issue41199@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20564
pull_request: https://github.com/python/cpython/pull/21415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:17:37 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 09 Jul 2020 12:17:37 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1594297057.13.0.30741256621.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Any news?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41183>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:19:25 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Jul 2020 12:19:25 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594297165.29.0.394288835784.issue41199@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:20:29 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 12:20:29 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594297229.57.0.637258323958.issue41199@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b4beda1a865972dc6477fd84b1a96ff5ccbfb45a by Miss Islington (bot) in branch '3.9':
bpo-41199: Docstring convention not followed for dataclasses documentation page (GH-21413)
https://github.com/python/cpython/commit/b4beda1a865972dc6477fd84b1a96ff5ccbfb45a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:21:15 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 12:21:15 +0000
Subject: [issue41199] Docstring convention not followed for dataclasses
 documentation page
In-Reply-To: <1593738613.53.0.928151938182.issue41199@roundup.psfhosted.org>
Message-ID: <1594297275.44.0.496258584099.issue41199@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1e66f7e102b64da5a6d69b135cf7d82708aca231 by Miss Islington (bot) in branch '3.8':
bpo-41199: Docstring convention not followed for dataclasses documentation page (GH-21413)
https://github.com/python/cpython/commit/1e66f7e102b64da5a6d69b135cf7d82708aca231


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41199>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:40:24 2020
From: report at bugs.python.org (Nir Soffer)
Date: Thu, 09 Jul 2020 12:40:24 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1594298424.38.0.371797784387.issue40327@roundup.psfhosted.org>


Nir Soffer <nirsof at gmail.com> added the comment:

Does this really affect only python 3.7?

We see this in RHEL 8.2, using python 3.6.8:
https://bugzilla.redhat.com/show_bug.cgi?id=1837199#c69

Likely caused by:

    lvs = dict(self._lvs)

Without locking. self._lvs is a dict that may contain 1000's of items.

I'm not sure if this is relvant now for upstream, but backport to 3.6 would be useful.

----------
nosy: +nirs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:02:49 2020
From: report at bugs.python.org (Martin Panter)
Date: Thu, 09 Jul 2020 13:02:49 +0000
Subject: [issue41254] Add to/from string methods to datetime.timedelta
In-Reply-To: <1594277218.28.0.16887324914.issue41254@roundup.psfhosted.org>
Message-ID: <1594299769.7.0.458229398438.issue41254@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I don't know how much support this will get since there is already a str(timedelta) operation defined with a different format. But I don't like that format much. The day[s] part is too verbose, the H:MM:SS part could too easily be interpreted as D:HH:MM, and the result for negative deltas is horrible (-43 days, 23:59:55; see Issue 38701).

My favourite format for a duration is usually the HTML 5 format like

1w 0d 12h 0m 27s

Another option is ISO 8601 format:

P1W0DT12H0M27S

But both of these standards only go down to the seconds unit, so 50 ms has to be 0.05s or PT0.05S.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41254>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:20:11 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 09 Jul 2020 13:20:11 +0000
Subject: [issue40941] Merge generator.gi_running and frame executing flag into
 single frame state
In-Reply-To: <1591795992.13.0.468529987519.issue40941@roundup.psfhosted.org>
Message-ID: <1594300811.19.0.866749325557.issue40941@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

issue29590 is unrelated

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40941>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:23:34 2020
From: report at bugs.python.org (Saber Hayati)
Date: Thu, 09 Jul 2020 13:23:34 +0000
Subject: [issue41257] mimetypes.guess_extension('video/x-matroska') return
 wrong value
Message-ID: <1594301014.01.0.923541225883.issue41257@roundup.psfhosted.org>


New submission from Saber Hayati <saberhayati at gmail.com>:

Code:
import mimetypes
print(mimetypes.guess_extension('video/x-matroska'))
# return '.mpv' instead of '.mkv'

Python 3.8.3 on Linux

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 373402
nosy: Saber Hayati
priority: normal
severity: normal
status: open
title: mimetypes.guess_extension('video/x-matroska') return wrong value
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41257>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:25:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jul 2020 13:25:17 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594301117.65.0.546632699195.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 96a6a6d42be272a27562d98549bbffc0d1854669 by Hai Shi in branch 'master':
bpo-40275: Use new test.support helper submodules in tests (GH-21412)
https://github.com/python/cpython/commit/96a6a6d42be272a27562d98549bbffc0d1854669


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:27:31 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 09 Jul 2020 13:27:31 +0000
Subject: [issue29590] Incorrect stack traces when re-entering a
 generator/coroutine stack via .throw()
In-Reply-To: <1487341428.62.0.272190755105.issue29590@psf.upfronthosting.co.za>
Message-ID: <1594301251.21.0.965453243813.issue29590@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 8b33961e4bc4020d8b2d5b949ad9d5c669300e89 by Chris Jerdonek in branch 'master':
bpo-29590: fix stack trace for gen.throw() with yield from (#19896)
https://github.com/python/cpython/commit/8b33961e4bc4020d8b2d5b949ad9d5c669300e89


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29590>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:27:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 13:27:45 +0000
Subject: [issue29590] Incorrect stack traces when re-entering a
 generator/coroutine stack via .throw()
In-Reply-To: <1487341428.62.0.272190755105.issue29590@psf.upfronthosting.co.za>
Message-ID: <1594301265.42.0.197727804724.issue29590@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20565
pull_request: https://github.com/python/cpython/pull/21416

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29590>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:33:40 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 09 Jul 2020 13:33:40 +0000
Subject: [issue39981] Default values for AST Nodes
In-Reply-To: <1584386240.94.0.329600152717.issue39981@roundup.psfhosted.org>
Message-ID: <1594301620.88.0.236941066598.issue39981@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
pull_requests: +20566
pull_request: https://github.com/python/cpython/pull/21417

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39981>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:59:51 2020
From: report at bugs.python.org (Matthew Hughes)
Date: Thu, 09 Jul 2020 13:59:51 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
In-Reply-To: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>
Message-ID: <1594303191.17.0.587388901487.issue41255@roundup.psfhosted.org>


Matthew Hughes <matthewhughes934 at gmail.com> added the comment:

I've attached a patch containing tests showing the current behavior, namely that exit_on_error does not change the behavior of argparse.ArgumentParser.parse_args in either case:

* An unrecognized option is given
* A required option is not given

Should the docs be updated to note this?

----------
keywords: +patch
Added file: https://bugs.python.org/file49310/exit_on_error_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:09:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jul 2020 14:09:03 +0000
Subject: [issue41258] CVE-2020-14422
Message-ID: <1594303743.77.0.551962800467.issue41258@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: vstinner
priority: normal
severity: normal
status: open
title: CVE-2020-14422

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41258>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:09:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jul 2020 14:09:11 +0000
Subject: [issue41258] CVE-2020-14422
Message-ID: <1594303751.47.0.981442466133.issue41258@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41258>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:09:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jul 2020 14:09:45 +0000
Subject: [issue41004] [CVE-2020-14422] Hash collisions in IPv4Interface and
 IPv6Interface
In-Reply-To: <1592399512.32.0.283218763722.issue41004@roundup.psfhosted.org>
Message-ID: <1594303785.15.0.958448575203.issue41004@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Hash collisions in IPv4Interface and IPv6Interface -> [CVE-2020-14422] Hash collisions in IPv4Interface and IPv6Interface

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41004>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:53:52 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Thu, 09 Jul 2020 15:53:52 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1594310032.63.0.218719718911.issue1635741@roundup.psfhosted.org>


Change by mohamed koubaa <koubaa.m at gmail.com>:


----------
pull_requests: +20567
pull_request: https://github.com/python/cpython/pull/21418

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Jul  9 12:42:02 2020
From: report at bugs.python.org (Rim Chatti)
Date: Thu, 09 Jul 2020 16:42:02 +0000
Subject: [issue41259] Find adverbs is not correct
Message-ID: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>


New submission from Rim Chatti <chattiriim at gmail.com>:

re.findall(r"\w+ly", text) does not find all adverbs in a sentence, it finds words that contain ly (not ending with ly) :
if text= 'andlying clearly', output: [andly, clearly]
which is wrong! 
the right way to do this is re.findall(r'\b(\w+ly)\b',text)
output= clearly!

----------
assignee: docs at python
components: Documentation
messages: 373406
nosy: Rim Chatti, docs at python
priority: normal
severity: normal
status: open
title: Find adverbs is not correct
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Thu Jul  9 12:43:10 2020
From: report at bugs.python.org (Rim Chatti)
Date: Thu, 09 Jul 2020 16:43:10 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1594312990.96.0.72814900655.issue41259@roundup.psfhosted.org>


Change by Rim Chatti <chattiriim at gmail.com>:


----------
title: Find adverbs is not correct -> Find adverbs is not correct on the documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:01:48 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 09 Jul 2020 17:01:48 +0000
Subject: [issue41260] datetime: strftime method takes different keyword
 argument: fmt (pure) or format (C)
Message-ID: <1594314108.83.0.615817711225.issue41260@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

C:

https://github.com/python/cpython/blob/8b33961e4bc4020d8b2d5b949ad9d5c669300e89/Modules/_datetimemodule.c#L3183

pure python:

https://github.com/python/cpython/blob/8b33961e4bc4020d8b2d5b949ad9d5c669300e89/Lib/datetime.py#L927


this makes it difficult to properly type in mypy:

https://github.com/python/typeshed/blob/209b6bb127f61fe173a60776e23883ac450cf1c8/stdlib/2and3/datetime.pyi#L55

and calling with `.strftime(fmt=...)` or `.strftime(format=...)` is inconsistent

(that said, it should _probably_ be a positional-only argument)

----------
components: Extension Modules, Library (Lib)
messages: 373407
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: datetime: strftime method takes different keyword argument: fmt (pure) or format (C)
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41260>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:37:46 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Jul 2020 17:37:46 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594316266.84.0.425386659897.issue41202@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> So how about maybe:   

That wouldn't work. You still haven't explained what's wrong with calling `loop = asyncio.get_running_loop()` inside `async def main()`. That literally solves all problems without the need of us modifying any APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:39:05 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Jul 2020 17:39:05 +0000
Subject: [issue41247] asyncio.set_running_loop() cache running loop holder
In-Reply-To: <1594234814.85.0.697243284436.issue41247@roundup.psfhosted.org>
Message-ID: <1594316345.17.0.117642679993.issue41247@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 0b6169e391ce6468aad711f08ffb829362293ad5 by Tony Solomonik in branch '3.8':
bpo-41247: asyncio.set_running_loop() cache running loop holder (#21406)
https://github.com/python/cpython/commit/0b6169e391ce6468aad711f08ffb829362293ad5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41247>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:45:53 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Jul 2020 17:45:53 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1594316753.52.0.983223526097.issue37179@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The aiohttp issue says they won't fix this until asyncio supports it. Kinda understand that.

I saw you opened an issue with aiohttp to allow this and they're open to it. I hope that will get some movement. It also would be a big test for uvloop's (and 3.10 asyncio) TLS implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:52:08 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jul 2020 17:52:08 +0000
Subject: [issue41260] datetime: strftime method takes different keyword
 argument: fmt (pure) or format (C)
In-Reply-To: <1594314108.83.0.615817711225.issue41260@roundup.psfhosted.org>
Message-ID: <1594317128.8.0.86738254065.issue41260@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41260>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:52:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 09 Jul 2020 17:52:47 +0000
Subject: [issue41172] test_peg_generator C tests fail on Windows ARM
In-Reply-To: <1593532643.61.0.103127847831.issue41172@roundup.psfhosted.org>
Message-ID: <1594317167.04.0.123053944229.issue41172@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset af56c4fc76ac39ce76d649d7bebf7f78c1add4fa by Steve Dower in branch 'master':
bpo-41172: Fix check for compiler in test suite (GH-21400)
https://github.com/python/cpython/commit/af56c4fc76ac39ce76d649d7bebf7f78c1add4fa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41172>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:53:18 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 17:53:18 +0000
Subject: [issue41172] test_peg_generator C tests fail on Windows ARM
In-Reply-To: <1593532643.61.0.103127847831.issue41172@roundup.psfhosted.org>
Message-ID: <1594317198.68.0.988711816574.issue41172@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +20568
pull_request: https://github.com/python/cpython/pull/21419

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41172>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:55:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 09 Jul 2020 17:55:24 +0000
Subject: [issue41172] test_peg_generator C tests fail on Windows ARM
In-Reply-To: <1593532643.61.0.103127847831.issue41172@roundup.psfhosted.org>
Message-ID: <1594317324.03.0.539768734815.issue41172@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41172>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:04:24 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jul 2020 18:04:24 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1594317864.67.0.781454228424.issue41259@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please submit a PR.

The parenthesis are not needed:
   re.findall(r"\b\w+ly\b", text)

----------
keywords: +easy
nosy: +rhettinger
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:05:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jul 2020 18:05:47 +0000
Subject: [issue41250] Number separators in different places
In-Reply-To: <1594258221.41.0.149493736122.issue41250@roundup.psfhosted.org>
Message-ID: <1594317947.82.0.130511786934.issue41250@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for the suggestion, but we'll decline for the reasons listed in the PEP and those listed by Eric.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41250>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:07:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jul 2020 18:07:44 +0000
Subject: [issue33754] f-strings should be part of the Grammar
In-Reply-To: <1528030778.27.0.592728768989.issue33754@psf.upfronthosting.co.za>
Message-ID: <1594318064.15.0.256164636736.issue33754@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I share Eric's concern about "unknowingly changing the behavior of f-strings."

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33754>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:12:14 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 18:12:14 +0000
Subject: [issue41172] test_peg_generator C tests fail on Windows ARM
In-Reply-To: <1593532643.61.0.103127847831.issue41172@roundup.psfhosted.org>
Message-ID: <1594318334.65.0.766300487461.issue41172@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c65ee555124a5647b8e3a5d58c906fa5db9e927a by Miss Islington (bot) in branch '3.9':
bpo-41172: Fix check for compiler in test suite (GH-21400)
https://github.com/python/cpython/commit/c65ee555124a5647b8e3a5d58c906fa5db9e927a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41172>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:18:43 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jul 2020 18:18:43 +0000
Subject: [issue40832] hi param in bisect module should not accept negative
 values
In-Reply-To: <1590909361.92.0.18411743492.issue40832@roundup.psfhosted.org>
Message-ID: <1594318723.52.0.149255057912.issue40832@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If the implementation made it easy, I would add the check.  But since it would be an invasive change, I'm inclined to pass on it because it is so uncommon ? the lo and hi arguments are rarely used, even more rarely with a negative hi paired with a non-negative lo  ? I've never seen this arise in practice ever.

If someone does find a real-world case where this was problematic, feel free to reopen this and we'll find a way to squeeze in the extra range check.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40832>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:23:38 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 09 Jul 2020 18:23:38 +0000
Subject: [issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when
 the _ast module is loaded more than once
In-Reply-To: <1593682119.68.0.42848291784.issue41194@roundup.psfhosted.org>
Message-ID: <1594319018.78.0.527728412039.issue41194@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

Ok, then. I'll open a new bug.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41194>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:25:50 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 09 Jul 2020 18:25:50 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
Message-ID: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>


New submission from Arcadiy Ivanov <arcadiy at ivanov.biz>:

"Short" reproducer:


repro.py:

```
import sys
from os import getcwd, chdir
from runpy import run_path


def smoke_test(script, *args):
    old_argv = list(sys.argv)
    del sys.argv[:]
    sys.argv.append(script)
    sys.argv.extend(args)

    old_modules = dict(sys.modules)
    old_meta_path = list(sys.meta_path)
    old_cwd = getcwd()

    try:
        return run_path(script, run_name="__main__")
    except SystemExit as e:
        if e.code:
            print("Test did not exit successfully")
    finally:
        del sys.argv[:]
        sys.argv.extend(old_argv)

        sys.modules.clear()
        sys.modules.update(old_modules)

        del sys.meta_path[:]
        sys.meta_path.extend(old_meta_path)
        chdir(old_cwd)


smoke_test("script.py")

smoke_test("script.py")
```

script.py:

```
import sys
import subprocess    
import ast

_PYTHON_INFO_SCRIPT = """import platform, sys, os, sysconfig
_executable = os.path.normcase(os.path.abspath(getattr(sys, "_base_executable", sys.executable)))
_platform = sys.platform
if _platform == "linux2":
    _platform = "linux"
print({
    "_platform": _platform,
    "_os_name": os.name,
    "_executable": (_executable, ),
    "_exec_dir": os.path.normcase(os.path.abspath(os.path.dirname(_executable))),
    "_name": platform.python_implementation(),
    "_type": platform.python_implementation().lower(),
    "_version": tuple(sys.version_info),
    "_is_pypy": "__pypy__" in sys.builtin_module_names,
    "_is_64bit": (getattr(sys, "maxsize", None) or getattr(sys, "maxint")) > 2 ** 32,
    "_versioned_dir_name": "%s-%s" % (platform.python_implementation().lower(), ".".join(str(f) for f in sys.version_info)),
    "_environ": dict(os.environ),
    "_darwin_python_framework": sysconfig.get_config_var("PYTHONFRAMEWORK")
})
"""

result = subprocess.check_output([sys.executable, "-c", _PYTHON_INFO_SCRIPT], universal_newlines=True)
python_info = ast.literal_eval(result)
print(python_info)

```

----------
components: Interpreter Core
messages: 373418
nosy: arcivanov
priority: normal
severity: normal
status: open
title: 3.9-dev SEGV in object_recursive_isinstance in ast.literal_eval
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:27:21 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 09 Jul 2020 18:27:21 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594319241.51.0.673500673595.issue41261@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

This is in the 3.9 branch as of a0a6f1167834c87f12e2eca11dd77143103e7691

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:26:31 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 09 Jul 2020 18:26:31 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594319191.28.0.0999705597402.issue41261@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

$ PYTHONWARNINGS=ignore gdb --args /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python ./repro.py 
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python...
(gdb) run
Starting program: /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python ./repro.py
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.31-2.fc32.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 185113]
{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac8589a5eebfb3e6b0', 'DEV_HOME': '/home/arcivanov/devhome/current', 'MY_RUBY_HOME': '/home/arcivanov/.rvm/rubies/ruby-2.4.3', 'ANT_HOME': '/home/arcivanov/devhome/current/ant', 'XDM_MANAGED': 'method=classic', 'DESKTOP_SESSION': 'default', 'RBENV_SHELL': 'bash', 'SSH_AGENT_PID': '5854', 'GTK_RC_FILES': '/etc/gtk/gtkrc:/home/arcivanov/.gtkrc:/home/arcivanov/.config/gtkrc', 'GDK_CORE_DEVICE_EVENTS': '1', 'XCURSOR_SIZE': '32', 'RUBY_VERSION': 'ruby-2.4.3', 'XDG_SEAT': 'seat0', 'PWD': '/home/arcivanov/Documents/src/arcivanov/pybuilder', 'PYENV_VIRTUALENV_INIT': '1', 'LOGNAME': 'arcivanov', 'XDG_SESSION_TYPE': 'x11', 'MODULESHOME': '/usr/share/Modules', 'rvm_version': '1.29.10 (latest)', 'MANPATH': '/home/arcivanov/devhome/current/jdk/man:/home/arcivanov/devhome/current/postgres-xl/share/man:/home/arcivanov/devhome/current/haproxy/share/man:/home/arcivanov/devhome/current/jdk/man:/home/arcivanov/devhome/current/postgres-xl/share/man:/home/arcivanov/devhome/current/haproxy/share/man::', '_': '/usr/bin/gdb', 'XAUTHORITY': '/tmp/xauth-1000-_0', 'SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS': '0', 'WINDOWPATH': '1', 'LINES': '221', 'GTK2_RC_FILES': '/etc/gtk-2.0/gtkrc:/home/arcivanov/.gtkrc-2.0:/home/arcivanov/.gtkrc-2.0-kde4:/home/arcivanov/.config/gtkrc-2.0', 'HOME': '/home/arcivanov', 'SSH_ASKPASS': '/usr/bin/ksshaskpass', 'LANG': 'en_US.UTF-8', 'LS_COLORS': 'rs=0:di=38;5;33:ln=38;5;51:mh=00:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=01;37;41:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;40:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.zst=38;5;9:*.tzst=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.wim=38;5;9:*.swm=38;5;9:*.dwm=38;5;9:*.esd=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.mjpg=38;5;13:*.mjpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.webp=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:', 'XDG_CURRENT_DESKTOP': 'KDE', 'KONSOLE_DBUS_SERVICE': ':1.34', 'COLUMNS': '267', 'VIRTUAL_ENV': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/envs/pyb-3.9-dev-d', 'KONSOLE_DBUS_SESSION': '/Sessions/7', 'PROFILEHOME': '', 'M2_HOME': '/home/arcivanov/devhome/current/maven', 'KONSOLE_VERSION': '200401', 'STEAM_FRAME_FORCE_CLOSE': '1', 'KDE_SESSION_UID': '1000', 'rvm_bin_path': '/home/arcivanov/.rvm/bin', 'GEM_PATH': '/home/arcivanov/.rvm/gems/ruby-2.4.3:/home/arcivanov/.rvm/gems/ruby-2.4.3 at global', 'GEM_HOME': '/home/arcivanov/.rvm/gems/ruby-2.4.3', 'MODULEPATH_modshare': '/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1', 'XDG_SESSION_CLASS': 'user', 'TERM': 'xterm-256color', 'LESSOPEN': '||/usr/bin/lesspipe.sh %s', 'USER': 'arcivanov', 'COLORFGBG': '15;0', 'MODULES_RUN_QUARANTINE': 'LD_LIBRARY_PATH', 'KDE_SESSION_VERSION': '5', 'PAM_KWALLET5_LOGIN': '/run/user/1000/kwallet5.socket', 'MAVEN_HOME': '/home/arcivanov/devhome/current/maven', 'LOADEDMODULES': '', 'DISPLAY': ':0', 'SHLVL': '1', 'XDG_VTNR': '1', 'XDG_SESSION_ID': '1', 'XDG_RUNTIME_DIR': '/run/user/1000', 'DM_CONTROL': '/var/run/xdmctl', 'PYENV_ROOT': '/home/arcivanov/.pyenv', 'KDEDIRS': '/usr', 'MAVEN_OPTS': '', 'QT_AUTO_SCREEN_SCALE_FACTOR': '0', 'XCURSOR_THEME': 'Adwaita', 'XDG_DATA_DIRS': '/home/arcivanov/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share', 'KDE_FULL_SESSION': 'true', 'PATH': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/envs/pyb-3.9-dev-d/bin:/home/arcivanov/.pyenv/plugins/pyenv-virtualenv/shims:/home/arcivanov/.pyenv/shims:/home/arcivanov/.pyenv/bin:/home/arcivanov/.rbenv/shims:/home/arcivanov/.rbenv/bin:/home/arcivanov/.rvm/gems/ruby-2.4.3/bin:/home/arcivanov/.rvm/gems/ruby-2.4.3 at global/bin:/home/arcivanov/.rvm/rubies/ruby-2.4.3/bin:/home/arcivanov/devhome/current/jdk/bin:/home/arcivanov/devhome/current/ant/bin:/home/arcivanov/devhome/current/maven/bin:/home/arcivanov/.pyenv/plugins/pyenv-virtualenv/shims:/home/arcivanov/.pyenv/shims:/home/arcivanov/.pyenv/bin:/home/arcivanov/.rbenv/shims:/home/arcivanov/.rbenv/bin:/home/arcivanov/devhome/current/jdk/bin:/home/arcivanov/devhome/current/ant/bin:/home/arcivanov/devhome/current/maven/bin:/usr/share/Modules/bin:/usr/lib64/ccache:/home/arcivanov/.rvm/gems/ruby-2.4.3/bin:/home/arcivanov/.rvm/gems/ruby-2.4.3 at global/bin:/home/arcivanov/.rvm/rubies/ruby-2.4.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/arcivanov/.rvm/bin:/usr/local/sbin:/usr/sbin', 'MODULEPATH': '/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles', 'DBUS_SESSION_BUS_ADDRESS': 'unix:path=/run/user/1000/bus', 'PYTHONWARNINGS': 'ignore', 'MAIL': '/var/spool/mail/arcivanov', 'IRBRC': '/home/arcivanov/.rvm/rubies/ruby-2.4.3/.irbrc', 'rvm_path': '/home/arcivanov/.rvm', 'OLDPWD': '/home/arcivanov/Documents/src', 'MODULES_CMD': '/usr/share/Modules/libexec/modulecmd.tcl', 'BASH_FUNC_switchml%%': '() {  typeset swfound=1;\n if [ "${MODULES_USE_COMPAT_VERSION:-0}" = \'1\' ]; then\n typeset swname=\'main\';\n if [ -e /usr/share/Modules/libexec/modulecmd.tcl ]; then\n typeset swfound=0;\n unset MODULES_USE_COMPAT_VERSION;\n fi;\n else\n typeset swname=\'compatibility\';\n if [ -e /usr/share/Modules/libexec/modulecmd-compat ]; then\n typeset swfound=0;\n MODULES_USE_COMPAT_VERSION=1;\n export MODULES_USE_COMPAT_VERSION;\n fi;\n fi;\n if [ $swfound -eq 0 ]; then\n echo "Switching to Modules $swname version";\n source /usr/share/Modules/init/bash;\n else\n echo "Cannot switch to Modules $swname version, command not found";\n return 1;\n fi\n}', 'BASH_FUNC_module%%': '() {  _module_raw "$@" 2>&1\n}', 'BASH_FUNC_scl%%': '() {  if [ "$1" = "load" -o "$1" = "unload" ]; then\n eval "module $@";\n else\n /usr/bin/scl "$@";\n fi\n}', 'BASH_FUNC__module_raw%%': '() {  unset _mlshdbg;\n if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = \'1\' ]; then\n case "$-" in \n *v*x*)\n set +vx;\n _mlshdbg=\'vx\'\n ;;\n *v*)\n set +v;\n _mlshdbg=\'v\'\n ;;\n *x*)\n set +x;\n _mlshdbg=\'x\'\n ;;\n *)\n _mlshdbg=\'\'\n ;;\n esac;\n fi;\n unset _mlre _mlIFS;\n if [ -n "${IFS+x}" ]; then\n _mlIFS=$IFS;\n fi;\n IFS=\' \';\n for _mlv in ${MODULES_RUN_QUARANTINE:-};\n do\n if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then\n if [ -n "`eval \'echo ${\'$_mlv\'+x}\'`" ]; then\n _mlre="${_mlre:-}${_mlv}_modquar=\'`eval \'echo ${\'$_mlv\'}\'`\' ";\n fi;\n _mlrv="MODULES_RUNENV_${_mlv}";\n _mlre="${_mlre:-}${_mlv}=\'`eval \'echo ${\'$_mlrv\':-}\'`\' ";\n fi;\n done;\n if [ -n "${_mlre:-}" ]; then\n eval `eval ${_mlre}/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash \'"$@"\'`;\n else\n eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;\n fi;\n _mlstatus=$?;\n if [ -n "${_mlIFS+x}" ]; then\n IFS=$_mlIFS;\n else\n unset IFS;\n fi;\n unset _mlre _mlv _mlrv _mlIFS;\n if [ -n "${_mlshdbg:-}" ]; then\n set -$_mlshdbg;\n fi;\n unset _mlshdbg;\n return $_mlstatus\n}'}, '_darwin_python_framework': ''}
[Detaching after fork from child process 185114]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
128         return ob->ob_type == type;
Missing separate debuginfos, use: dnf debuginfo-install libxcrypt-4.4.16-3.fc32.x86_64
(gdb) 
(gdb) bt
#0  0x0000000000623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 <PyType_Type>) at ./Include/object.h:128
#1  0x0000000000623487 in _PyType_CheckExact (op=0x0) at ./Include/object.h:641
#2  0x0000000000628d85 in object_recursive_isinstance (tstate=0x8b19a0, 
    inst="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", cls=0x0) at Objects/abstract.c:2495
#3  0x0000000000628fdc in PyObject_IsInstance (
    inst="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", cls=0x0) at Objects/abstract.c:2551
#4  0x0000000000682420 in PyAST_Check (
    obj="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85") at Python/Python-ast.c:10356
#5  0x000000000069c754 in builtin_compile_impl (module=<module at remote 0x7fffeabc3a10>, 
    source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/jdk', 'SSH_AUTH_SOCK': '/tmp/ssh-2nZCuLIsvvyW/agent.5125', 'SHELL_SESSION_ID': '1fe1a56ee9dd4fac85", filename='<unknown>', mode=0x7fffeabc42f0 "eval", 
    flags=1024, dont_inherit=0, optimize=-1, feature_version=-1) at Python/bltinmodule.c:784
#6  0x000000000069aa72 in builtin_compile (module=<module at remote 0x7fffeabc3a10>, args=0x7fffffff02b0, nargs=4, kwnames=('_feature_version',)) at Python/clinic/bltinmodule.c.h:274
#7  0x0000000000655297 in cfunction_vectorcall_FASTCALL_KEYWORDS (func=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0x9c8a00, nargsf=9223372036854775812, kwnames=('_feature_version',)) at Objects/methodobject.c:440
#8  0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0x9c8a00, nargsf=9223372036854775812, kwnames=('_feature_version',)) at ./Include/cpython/abstract.h:118
#9  0x0000000000509a90 in PyObject_Vectorcall (callable=<built-in method compile of module object at remote 0x7fffeabc3a10>, args=0x9c8a00, nargsf=9223372036854775812, kwnames=('_feature_version',)) at ./Include/cpython/abstract.h:127
#10 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff0518, oparg=5, kwnames=('_feature_version',)) at Python/ceval.c:5044
#11 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x9c8850, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated), throwflag=0)
    at Python/ceval.c:3507
#12 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x9c8850, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#13 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffea863ee0>, 
    globals={'__name__': 'ast', '__doc__': '\n    ast\n    ~~~\n\n    The `ast` module helps Python applications to process trees of the Python\n    abstract syntax grammar.  The abstract syntax itself might change with\n    each Python release; this module helps to find out programmatically what\n    the current grammar looks like and allows modifications of it.\n\n    An abstract syntax tree can be generated by passing `ast.PyCF_ONLY_AST` as\n    a flag to the `compile()` builtin function or by using the `parse()`\n    function from this module.  The result will be a tree of objects whose\n    classes all inherit from `ast.AST`.\n\n    A modified abstract syntax tree can be compiled into a Python code object\n    using the built-in `compile()` function.\n\n    Additionally various helper functions are provided that make working with\n    the trees simpler.  The main intention of the helper functions and this\n    module in general is to provide an easy to use interface for libraries\n    that work tightly with the pyth...(truncated), locals=0x0, 
    args=0x7fffea8161e8, argcount=1, kwnames=0x7fffea7fc3d8, kwargs=0x7fffea8161f0, kwcount=1, kwstep=1, defs=0x7fffea8ab978, defcount=2, kwdefs={'type_comments': False, 'feature_version': None}, closure=0x0, name='parse', qualname='parse') at Python/ceval.c:4299
#14 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea7cc410>, stack=0x7fffea8161e8, nargsf=9223372036854775809, kwnames=('mode',)) at Objects/call.c:395
#15 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea7cc410>, args=0x7fffea8161e8, nargsf=9223372036854775809, kwnames=('mode',)) at ./Include/cpython/abstract.h:118
#16 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea7cc410>, args=0x7fffea8161e8, nargsf=9223372036854775809, kwnames=('mode',)) at ./Include/cpython/abstract.h:127
#17 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff1d38, oparg=2, kwnames=('mode',)) at Python/ceval.c:5044
#18 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x7fffea816050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated), throwflag=0)
    at Python/ceval.c:3507
#19 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x7fffea816050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#20 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffea876930>, 
    globals={'__name__': 'ast', '__doc__': '\n    ast\n    ~~~\n\n    The `ast` module helps Python applications to process trees of the Python\n    abstract syntax grammar.  The abstract syntax itself might change with\n    each Python release; this module helps to find out programmatically what\n    the current grammar looks like and allows modifications of it.\n\n    An abstract syntax tree can be generated by passing `ast.PyCF_ONLY_AST` as\n    a flag to the `compile()` builtin function or by using the `parse()`\n    function from this module.  The result will be a tree of objects whose\n    classes all inherit from `ast.AST`.\n\n    A modified abstract syntax tree can be compiled into a Python code object\n    using the built-in `compile()` function.\n\n    Additionally various helper functions are provided that make working with\n    the trees simpler.  The main intention of the helper functions and this\n    module in general is to provide an easy to use interface for libraries\n    that work tightly with the pyth...(truncated), locals=0x0, 
    args=0x7fffea9321c8, argcount=1, kwnames=0x0, kwargs=0x7fffea9321d0, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='literal_eval', qualname='literal_eval') at Python/ceval.c:4299
#21 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea7f7e10>, stack=0x7fffea9321c8, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:395
#22 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea7f7e10>, args=0x7fffea9321c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#23 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea7f7e10>, args=0x7fffea9321c8, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#24 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff3578, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#25 0x00000000005193a1 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, f=Frame 0x7fffea932050, for file script.py, line 27, in <module> (), throwflag=0) at Python/ceval.c:3459
#26 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, f=Frame 0x7fffea932050, for file script.py, line 27, in <module> (), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#27 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), args=0x0, 
    argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
#28 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), args=0x0, 
    argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4331
#29 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), args=0x0, 
    argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#30 0x000000000050bbc0 in PyEval_EvalCode (co=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated))
    at Python/ceval.c:809
#31 0x000000000069ce37 in builtin_exec_impl (module=<module at remote 0x7fffeabc3a10>, source=<code at remote 0x7fffeaab9450>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated), 
    locals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all': <built-in method all of module object at remote 0x7fffeabc3a10>, 'any': <built-in method any of module object at remote 0x7fffeabc3a10>, 'ascii': <built-in method asci...(truncated))
    at Python/bltinmodule.c:1035
#32 0x000000000069ac76 in builtin_exec (module=<module at remote 0x7fffeabc3a10>, args=0x9b3e60, nargs=2) at Python/clinic/bltinmodule.c.h:396
#33 0x00000000006551f4 in cfunction_vectorcall_FASTCALL (func=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0x9b3e60, nargsf=9223372036854775810, kwnames=0x0) at Objects/methodobject.c:424
#34 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0x9b3e60, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:118
#35 0x0000000000509a90 in PyObject_Vectorcall (callable=<built-in method exec of module object at remote 0x7fffeabc3a10>, args=0x9b3e60, nargsf=9223372036854775810, kwnames=0x0) at ./Include/cpython/abstract.h:127
#36 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff4f18, oparg=2, kwnames=0x0) at Python/ceval.c:5044
#37 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x9b3ca0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffeaab9450>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all'...(truncated), throwflag=0)
    at Python/ceval.c:3490
#38 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x9b3ca0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffeaab9450>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all'...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#39 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaab9790>, 
    globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffeaa980a0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffeaa980f0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, 
    args=0x9b3c18, argcount=7, kwnames=0x0, kwargs=0x9b3c50, kwcount=0, kwstep=1, defs=0x7fffeaaaaed8, defcount=5, kwdefs=0x0, closure=0x0, name='_run_code', qualname='_run_code') at Python/ceval.c:4299
#40 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffeab9bd70>, stack=0x9b3c18, nargsf=9223372036854775815, kwnames=0x0) at Objects/call.c:395
#41 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffeab9bd70>, args=0x9b3c18, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:118
#42 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffeab9bd70>, args=0x9b3c18, nargsf=9223372036854775815, kwnames=0x0) at ./Include/cpython/abstract.h:127
#43 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff6738, oparg=7, kwnames=0x0) at Python/ceval.c:5044
#44 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x9b3a50, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffeaab9450>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='script.py', fname='script.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffea7f4f50>, _saved_module=[<module at remote 0x7fffeab12b90>]) at remote 0x7fffea917aa0>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) a...(truncated), throwflag=0)
    at Python/ceval.c:3490
#45 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x9b3a50, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffeaab9450>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='script.py', fname='script.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffea7f4f50>, _saved_module=[<module at remote 0x7fffeab12b90>]) at remote 0x7fffea917aa0>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) a...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#46 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaab9860>, 
    globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffeaa980a0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffeaa980f0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, 
    args=0x994310, argcount=3, kwnames=0x7fffeaa98568, kwargs=0x994328, kwcount=2, kwstep=1, defs=0x7fffeaab6928, defcount=5, kwdefs=0x0, closure=0x0, name='_run_module_code', qualname='_run_module_code') at Python/ceval.c:4299
#47 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e7af0>, stack=0x994310, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at Objects/call.c:395
#48 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea8e7af0>, args=0x994310, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at ./Include/cpython/abstract.h:118
#49 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea8e7af0>, args=0x994310, nargsf=9223372036854775811, kwnames=('pkg_name', 'script_name')) at ./Include/cpython/abstract.h:127
#50 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff7f48, oparg=5, kwnames=('pkg_name', 'script_name')) at Python/ceval.c:5044
#51 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x994140, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='script.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffeaab9450>, fname='script.py'), throwflag=0) at Python/ceval.c:3507
#52 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x994140, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='script.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffeaab9450>, fname='script.py'), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#53 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaa9c040>, 
    globals={'__name__': 'runpy', '__doc__': 'runpy.py - locating and running Python code using the module namespace\n\nProvides support for locating and running Python scripts using the Python\nmodule namespace instead of the native filesystem.\n\nThis allows Python code to play nicely with non-filesystem based PEP 302\nimporters when locating support scripts as well as when importing modules.\n', '__package__': '', '__loader__': <SourceFileLoader(name='runpy', path='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py') at remote 0x7fffeaa980a0>, '__spec__': <ModuleSpec(name='runpy', loader=<...>, origin='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/__pycache__/runpy.cpython-39.pyc', _initializing=False) at remote 0x7fffeaa980f0>, '__file__': '/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py', '__cached__': '/home/arciv...(truncated), locals=0x0, 
    args=0x969508, argcount=1, kwnames=0x7fffeabcd478, kwargs=0x969510, kwcount=1, kwstep=1, defs=0x7fffeaa98608, defcount=2, kwdefs=0x0, closure=0x0, name='run_path', qualname='run_path') at Python/ceval.c:4299
#54 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffea8e7eb0>, stack=0x969508, nargsf=9223372036854775809, kwnames=('run_name',)) at Objects/call.c:395
#55 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffea8e7eb0>, args=0x969508, nargsf=9223372036854775809, kwnames=('run_name',)) at ./Include/cpython/abstract.h:118
#56 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffea8e7eb0>, args=0x969508, nargsf=9223372036854775809, kwnames=('run_name',)) at ./Include/cpython/abstract.h:127
#57 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffff9768, oparg=2, kwnames=('run_name',)) at Python/ceval.c:5044
#58 0x00000000005197ff in _PyEval_EvalFrameDefault (tstate=0x8b19a0, 
    f=Frame 0x969360, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 17, in smoke_test (script='script.py', args=(), old_argv=['./repro.py'], old_modules={'sys': <module at remote 0x7fffeabba2f0>, 'builtins': <module at remote 0x7fffeabc3a10>, '_frozen_importlib': <module at remote 0x7fffeab60a70>, '_imp': <module at remote 0x7fffeab60a10>, '_thread': <module at remote 0x7fffeab6e3b0>, '_warnings': <module at remote 0x7fffeab6ef50>, '_weakref': <module at remote 0x7fffeab6f350>, '_frozen_importlib_external': <module at remote 0x7fffeab6fcb0>, 'posix': <module at remote 0x7fffeab6fb30>, '_io': <module at remote 0x7fffeab33290>, 'marshal': <module at remote 0x7fffeab3bdd0>, 'time': <module at remote 0x7fffeab47290>, 'zipimport': <module at remote 0x7fffeab3d350>, '_codecs': <module at remote 0x7fffeaaeaa10>, 'codecs': <module at remote 0x7fffeab57710>, 'encodings.aliases': <module at remote 0x7fffeaaea5f0>, 'encodings': <module at remote 0x7fffeab4d830>, 'encodings.utf_8': <module at remo...(truncated), throwflag=0)
    at Python/ceval.c:3507
#59 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, 
    f=Frame 0x969360, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 17, in smoke_test (script='script.py', args=(), old_argv=['./repro.py'], old_modules={'sys': <module at remote 0x7fffeabba2f0>, 'builtins': <module at remote 0x7fffeabc3a10>, '_frozen_importlib': <module at remote 0x7fffeab60a70>, '_imp': <module at remote 0x7fffeab60a10>, '_thread': <module at remote 0x7fffeab6e3b0>, '_warnings': <module at remote 0x7fffeab6ef50>, '_weakref': <module at remote 0x7fffeab6f350>, '_frozen_importlib_external': <module at remote 0x7fffeab6fcb0>, 'posix': <module at remote 0x7fffeab6fb30>, '_io': <module at remote 0x7fffeab33290>, 'marshal': <module at remote 0x7fffeab3bdd0>, 'time': <module at remote 0x7fffeab47290>, 'zipimport': <module at remote 0x7fffeab3d350>, '_codecs': <module at remote 0x7fffeaaeaa10>, 'codecs': <module at remote 0x7fffeab57710>, 'encodings.aliases': <module at remote 0x7fffeaaea5f0>, 'encodings': <module at remote 0x7fffeab4d830>, 'encodings.utf_8': <module at remo...(truncated), throwflag=0)
    at ./Include/internal/pycore_ceval.h:40
#60 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaaa2a00>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals=0x0, args=0x910810, argcount=1, kwnames=0x0, kwargs=0x910818, kwcount=0, kwstep=1, 
    defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='smoke_test', qualname='smoke_test') at Python/ceval.c:4299
#61 0x0000000000431853 in _PyFunction_Vectorcall (func=<function at remote 0x7fffeaaa8190>, stack=0x910810, nargsf=9223372036854775809, kwnames=0x0) at Objects/call.c:395
#62 0x0000000000509a31 in _PyObject_VectorcallTstate (tstate=0x8b19a0, callable=<function at remote 0x7fffeaaa8190>, args=0x910810, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:118
#63 0x0000000000509a90 in PyObject_Vectorcall (callable=<function at remote 0x7fffeaaa8190>, args=0x910810, nargsf=9223372036854775809, kwnames=0x0) at ./Include/cpython/abstract.h:127
#64 0x000000000051ea52 in call_function (tstate=0x8b19a0, pp_stack=0x7fffffffaf98, oparg=1, kwnames=0x0) at Python/ceval.c:5044
#65 0x0000000000519598 in _PyEval_EvalFrameDefault (tstate=0x8b19a0, f=Frame 0x9106a0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 35, in <module> (), throwflag=0) at Python/ceval.c:3490
#66 0x0000000000509cde in _PyEval_EvalFrame (tstate=0x8b19a0, f=Frame 0x9106a0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 35, in <module> (), throwflag=0) at ./Include/internal/pycore_ceval.h:40
#67 0x000000000051cf4e in _PyEval_EvalCode (tstate=0x8b19a0, _co=<code at remote 0x7fffeaaa2d40>, 
    globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, 
    locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, 
    kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4299
--Type <RET> for more, q to quit, c to continue without paging--c
#68 0x000000000051d051 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fffeaaa2d40>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, args=0x0, argcount=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4331
#69 0x000000000051d0d9 in PyEval_EvalCodeEx (_co=<code at remote 0x7fffeaaa2d40>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4347
#70 0x000000000050bbc0 in PyEval_EvalCode (co=<code at remote 0x7fffeaaa2d40>, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}) at Python/ceval.c:809
#71 0x000000000056eaf9 in run_eval_code_obj (tstate=0x8b19a0, co=0x7fffeaaa2d40, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}) at Python/pythonrun.c:1178
#72 0x000000000056ebe2 in run_mod (mod=0x93a0d8, filename='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, flags=0x7fffffffc9a8, arena=0x7fffeaaa7b20) at Python/pythonrun.c:1199
#73 0x000000000056e971 in PyRun_FileExFlags (fp=0x8aebf0, filename_str=0x7fffeaa837e0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", start=257, globals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, locals={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py') at remote 0x7fffeab0abe0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module at remote 0x7fffeabc3a10>, '__file__': '/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py', '__cached__': None, 'sys': <module at remote 0x7fffeabba2f0>, 'getcwd': <built-in method getcwd of module object at remote 0x7fffeab6fb30>, 'chdir': <built-in method chdir of module object at remote 0x7fffeab6fb30>, 'run_path': <function at remote 0x7fffea8e7eb0>, 'smoke_test': <function at remote 0x7fffeaaa8190>}, closeit=1, flags=0x7fffffffc9a8) at Python/pythonrun.c:1116
#74 0x000000000056d447 in PyRun_SimpleFileExFlags (fp=0x8aebf0, filename=0x7fffeaa837e0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", closeit=1, flags=0x7fffffffc9a8) at Python/pythonrun.c:438
#75 0x000000000056c958 in PyRun_AnyFileExFlags (fp=0x8aebf0, filename=0x7fffeaa837e0 "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", closeit=1, flags=0x7fffffffc9a8) at Python/pythonrun.c:87
#76 0x000000000041e6e8 in pymain_run_file (config=0x8b0470, cf=0x7fffffffc9a8) at Modules/main.c:369
#77 0x000000000041ecd8 in pymain_run_python (exitcode=0x7fffffffc9ec) at Modules/main.c:594
#78 0x000000000041edc9 in Py_RunMain () at Modules/main.c:673
#79 0x000000000041ee43 in pymain_main (args=0x7fffffffca50) at Modules/main.c:703
#80 0x000000000041eebd in Py_BytesMain (argc=2, argv=0x7fffffffcb88) at Modules/main.c:727
#81 0x000000000041d786 in main (argc=2, argv=0x7fffffffcb88) at ./Programs/python.c:15
(gdb) py-bt-full
#7 <built-in method compile of module object at remote 0x7fffeabc3a10>
#11 Frame 0x9c8850, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 306, in parse (source="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivanov/devhome/current/j...(truncated)
    lines.append(next_line)
#18 Frame 0x7fffea816050, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py, line 62, in literal_eval (node_or_string="{'_platform': 'linux', '_os_name': 'posix', '_executable': ('/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python',), '_exec_dir': '/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin', '_name': 'CPython', '_type': 'cpython', '_version': (3, 9, 0, 'beta', 4), '_is_pypy': False, '_is_64bit': True, '_versioned_dir_name': 'cpython-3.9.0.beta.4', '_environ': {'SHELL': '/bin/bash', 'SESSION_MANAGER': 'local/unix:@/tmp/.ICE-unix/6175,unix/unix:/tmp/.ICE-unix/6175', 'WINDOWID': '56623111', 'COLORTERM': 'truecolor', 'PYENV_SHELL': 'bash', 'XDG_CONFIG_DIRS': '/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg', 'HISTCONTROL': 'ignoredups', 'XDG_MENU_PREFIX': 'kf5-', 'rvm_prefix': '/home/arcivanov', 'HISTSIZE': '-1', 'HOSTNAME': 'ai-karellen-lap', 'LANGUAGE': '', 'JAVA_HOME': '/home/arcivan...(truncated)
    node_or_string = parse(node_or_string, mode='eval')
#25 Frame 0x7fffea932050, for file script.py, line 27, in <module> ()
    python_info = ast.literal_eval(result)
#33 <built-in method exec of module object at remote 0x7fffeabc3a10>
#37 Frame 0x9b3ca0, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 343, in _run_code (code=<code at remote 0x7fffeaab9450>, run_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) at remote 0x7fffeab6a0f0>, '__build_class__': <built-in method __build_class__ of module object at remote 0x7fffeabc3a10>, '__import__': <built-in method __import__ of module object at remote 0x7fffeabc3a10>, 'abs': <built-in method abs of module object at remote 0x7fffeabc3a10>, 'all'...(truncated)
#44 Frame 0x9b3a50, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 353, in _run_module_code (code=<code at remote 0x7fffeaab9450>, init_globals=None, mod_name='__main__', mod_spec=None, pkg_name='', script_name='script.py', fname='script.py', temp_module=<_TempModule(mod_name='__main__', module=<module at remote 0x7fffea7f4f50>, _saved_module=[<module at remote 0x7fffeab12b90>]) at remote 0x7fffea917aa0>, mod_globals={'__name__': '__main__', '__doc__': None, '__package__': '', '__loader__': None, '__spec__': None, '__file__': 'script.py', '__cached__': None, '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <type at remote 0x8c35e0>, '__spec__': <ModuleSpec(name='builtins', loader=<type at remote 0x8c35e0>, origin='built-in', loader_state=None, submodule_search_locations=None, _set_fileattr=False, _cached=None) a...(truncated)
#51 Frame 0x994140, for file /home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py, line 524, in run_path (path_name='script.py', init_globals=None, run_name='__main__', pkg_name='', importer=None, is_NullImporter=False, code=<code at remote 0x7fffeaab9450>, fname='script.py')
#58 Frame 0x969360, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 17, in smoke_test (script='script.py', args=(), old_argv=['./repro.py'], old_modules={'sys': <module at remote 0x7fffeabba2f0>, 'builtins': <module at remote 0x7fffeabc3a10>, '_frozen_importlib': <module at remote 0x7fffeab60a70>, '_imp': <module at remote 0x7fffeab60a10>, '_thread': <module at remote 0x7fffeab6e3b0>, '_warnings': <module at remote 0x7fffeab6ef50>, '_weakref': <module at remote 0x7fffeab6f350>, '_frozen_importlib_external': <module at remote 0x7fffeab6fcb0>, 'posix': <module at remote 0x7fffeab6fb30>, '_io': <module at remote 0x7fffeab33290>, 'marshal': <module at remote 0x7fffeab3bdd0>, 'time': <module at remote 0x7fffeab47290>, 'zipimport': <module at remote 0x7fffeab3d350>, '_codecs': <module at remote 0x7fffeaaeaa10>, 'codecs': <module at remote 0x7fffeab57710>, 'encodings.aliases': <module at remote 0x7fffeaaea5f0>, 'encodings': <module at remote 0x7fffeab4d830>, 'encodings.utf_8': <module at remo...(truncated)
    return run_path(script, run_name="__main__")
#65 Frame 0x9106a0, for file /home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py, line 35, in <module> ()
    smoke_test("script.py")
(gdb) py-bt
Traceback (most recent call first):
  <built-in method compile of module object at remote 0x7fffeabc3a10>
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py", line 306, in parse
    lines.append(next_line)
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/ast.py", line 62, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "script.py", line 27, in <module>
    python_info = ast.literal_eval(result)
  <built-in method exec of module object at remote 0x7fffeabc3a10>
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 343, in _run_code
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 353, in _run_module_code
  File "/home/arcivanov/.pyenv/versions/3.9-dev-debug/lib/python3.9/runpy.py", line 524, in run_path
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", line 17, in smoke_test
    return run_path(script, run_name="__main__")
  File "/home/arcivanov/Documents/src/arcivanov/pybuilder/./repro.py", line 35, in <module>
    smoke_test("script.py")
(gdb)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:44:02 2020
From: report at bugs.python.org (Ruairidh MacLeod)
Date: Thu, 09 Jul 2020 18:44:02 +0000
Subject: [issue41260] datetime: strftime method takes different keyword
 argument: fmt (pure) or format (C)
In-Reply-To: <1594314108.83.0.615817711225.issue41260@roundup.psfhosted.org>
Message-ID: <1594320242.48.0.600126888632.issue41260@roundup.psfhosted.org>


Change by Ruairidh MacLeod <r.macleod at epcc.ed.ac.uk>:


----------
nosy: +rkm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41260>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:06:30 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 09 Jul 2020 19:06:30 +0000
Subject: [issue41260] datetime: strftime method takes different keyword
 argument: fmt (pure) or format (C)
In-Reply-To: <1594314108.83.0.615817711225.issue41260@roundup.psfhosted.org>
Message-ID: <1594321590.32.0.135345033902.issue41260@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think a positional-only argument would be the best option if we could do it, but it would be a backwards-incompatible change and it's probably not worth the hassle.

If anyone is using the keyword argument, they're probably using `format=` rather than `fmt=`, since it's pretty rare for anyone to use the pure python version of datetime. PyPy uses it, but I think they tend to aim for consistency with the C API of CPython, and it seems like they already patch s/fmt/format/ themselves: https://foss.heptapod.net/pypy/pypy/-/blob/branch/default/lib_pypy/datetime.py#L781

If anyone wants to make a PR I think we can fix this for 3.10, though unfortunately because it is an API change it can't be backported. I think in typeshed they can safely change from `fmt` to `format` even today (which would almost certainly be more accurate to end user use cases).

----------
nosy:  -rkm
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41260>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:08:45 2020
From: report at bugs.python.org (Rim Chatti)
Date: Thu, 09 Jul 2020 19:08:45 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1594321725.1.0.285868168797.issue41259@roundup.psfhosted.org>


Rim Chatti <chattiriim at gmail.com> added the comment:

re.findall(r"\w+ly", text) does not find all adverbs in a sentence, it finds words that contain ly (not ending with ly) :
if text= 'andlying clearly', output: [andly, clearly]
which is wrong! 
the right way to do this is re.findall(r'\b\w+ly\b',text)
output= clearly!

----------
components: +Regular Expressions -Documentation
keywords: +patch
message_count: 2.0 -> 3.0
nosy: +ezio.melotti, mrabarnett
nosy_count: 3.0 -> 5.0
pull_requests: +20569
stage:  -> patch review
type:  -> behavior
pull_request: https://github.com/python/cpython/pull/21420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:31:46 2020
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Jul 2020 19:31:46 +0000
Subject: [issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
In-Reply-To: <1594259955.25.0.153567227259.issue41251@roundup.psfhosted.org>
Message-ID: <1594323106.04.0.288160142993.issue41251@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for keeping the first 'F' in FLUFL!  :D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41251>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:42:04 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 09 Jul 2020 19:42:04 +0000
Subject: [issue41260] datetime: strftime method takes different keyword
 argument: fmt (pure) or format (C)
In-Reply-To: <1594314108.83.0.615817711225.issue41260@roundup.psfhosted.org>
Message-ID: <1594323724.26.0.412010860684.issue41260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

awesome, I'm going to work through this with someone in my discord as a demo / mentorship opportunity -- hope that's ok!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41260>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:48:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jul 2020 19:48:54 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
Message-ID: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR converts Objects/memoryobject.c to Argument Clinic.

Advantages:

* Highly optimized code is used to parse arguments instead of slow PyArg_ParseTupleAndKeywords().
* All future improvements of argument parsing (better performance or errors handling) will be automatically applied to memoryobject.

Previously Argument Clinic was used for memoryview.hex().

----------
components: Extension Modules
messages: 373425
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Convert memoryview to Argument Clinic
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:49:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jul 2020 19:49:12 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1594324152.13.0.199490793472.issue41262@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Argument Clinic, Interpreter Core -Extension Modules
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:50:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jul 2020 19:50:12 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1594324212.07.0.27158632668.issue41262@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20570
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21421

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:03:27 2020
From: report at bugs.python.org (Peter Otten)
Date: Thu, 09 Jul 2020 20:03:27 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1594325007.36.0.722223295811.issue41259@roundup.psfhosted.org>


Peter Otten <__peter__ at web.de> added the comment:

While I don't want to start a philosical discussion -- is that really better? Finding adverbs with a regex doesn't work in the general case -- think butterfly, panoply, well -- and the example is meant to illustrate the usage of re.findall() rather than regex syntax.

"finding adverbs" is just shorter and easier to understand than "finding sequences of word characters that end with "ly".

----------
nosy: +peter.otten

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:10:20 2020
From: report at bugs.python.org (Felipe A. Hernandez)
Date: Thu, 09 Jul 2020 20:10:20 +0000
Subject: [issue35919] multiprocessing: shared manager Pool fails with
 AttributeError
In-Reply-To: <1549474580.7.0.974775956703.issue35919@roundup.psfhosted.org>
Message-ID: <1594325420.21.0.0134943468042.issue35919@roundup.psfhosted.org>


Felipe A. Hernandez <ergoithz at gmail.com> added the comment:

import traceback
import multiprocessing.managers


class MyManager(multiprocessing.managers.SyncManager):
    pass

class DictList(multiprocessing.managers.BaseProxy):
    _method_to_typeid_ = {'__getitem__': 'dict'}

    def __getitem__(self, key):
        return self._callmethod('__getitem__', (key,))

MyManager.register('DictList', None, DictList)

with MyManager() as manager:

    nested = manager.DictList([{'hello': 'world'}])
    print(nested[0]['hello'])  # world

    proxy = manager.list([nested])
    try:
        print(proxy[0][0]['hello'])
    except AttributeError:
        traceback.print_exc()
        print("""
        Bug: AttributeError: ProxyBase._callmethod is None
        --------------------------------------------------

        This error is raised because proxies returned as #RETURN messages
        have no manager reference, which is required to resolve typeids
        (using BaseManager._registry).

        Only proxies returned as #PROXY messages will be fully functional.

        This is an undocumented current implementation limitation.

        Fix (proposal)
        --------------

        Include the manager class (not the instance) as part of the proxy
        serialization in BaseProxy.__reduce__, as BaseManager._registry is
        a class variable.

        Note: #PROXY message protocol can be also replaced by regular proxy
              serialization after this fix, resulting on simpler codebase.
        """)

----------
nosy: +Felipe A. Hernandez

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35919>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:12:44 2020
From: report at bugs.python.org (Felipe A. Hernandez)
Date: Thu, 09 Jul 2020 20:12:44 +0000
Subject: [issue35919] multiprocessing: shared manager Pool fails with
 AttributeError
In-Reply-To: <1549474580.7.0.974775956703.issue35919@roundup.psfhosted.org>
Message-ID: <1594325564.29.0.416602620893.issue35919@roundup.psfhosted.org>


Change by Felipe A. Hernandez <ergoithz at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +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/issue35919>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:14:31 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Thu, 09 Jul 2020 20:14:31 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594325671.24.0.283467172425.issue41261@roundup.psfhosted.org>


Change by Arcadiy Ivanov <arcadiy at ivanov.biz>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:21:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jul 2020 20:21:09 +0000
Subject: [issue41263] Convert code.__new__ to Argument Clinic
Message-ID: <1594326069.58.0.0732196430915.issue41263@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Argument Clinic is already used for code.replace(). The proposed PR converts code.__new__() to Argument Clinic.

----------
components: Argument Clinic, Installation
messages: 373428
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert code.__new__ to Argument Clinic
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41263>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:08:40 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2020 22:08:40 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594332520.73.0.323501659044.issue37765@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset bce2eb4646021910aa4074d86f44a09b32d0b2b2 by Terry Jan Reedy in branch 'master':
bpo-37765: Add keywords to IDLE tab completions (GH-15138)
https://github.com/python/cpython/commit/bce2eb4646021910aa4074d86f44a09b32d0b2b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:09:00 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 22:09:00 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594332540.14.0.519671329731.issue37765@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +20571
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21423

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:09:07 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 22:09:07 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594332547.72.0.513833877455.issue37765@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20572
pull_request: https://github.com/python/cpython/pull/21424

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:43:54 2020
From: report at bugs.python.org (daniel hahler)
Date: Thu, 09 Jul 2020 22:43:54 +0000
Subject: [issue38854] Decorator breaks inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1594334634.76.0.631483264382.issue38854@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:46:02 2020
From: report at bugs.python.org (daniel hahler)
Date: Thu, 09 Jul 2020 22:46:02 +0000
Subject: [issue38854] Decorator with paren tokens in arguments breaks
 inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1594334762.66.0.0918452017221.issue38854@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
title: Decorator breaks inspect.getsource -> Decorator with paren tokens in arguments breaks inspect.getsource

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:47:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2020 22:47:10 +0000
Subject: [issue27609] IDLE completions: format, factor, and fix
In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za>
Message-ID: <1594334830.43.0.210748775576.issue27609@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: https://bugs.python.org/msg373259

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27609>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:54:21 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 22:54:21 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594335261.3.0.184404815586.issue37765@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fd27fb7f3dd157294f05bb060f7efd243732ab2d by Miss Islington (bot) in branch '3.9':
bpo-37765: Add keywords to IDLE tab completions (GH-15138)
https://github.com/python/cpython/commit/fd27fb7f3dd157294f05bb060f7efd243732ab2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Thu Jul  9 18:54:47 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jul 2020 22:54:47 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594335287.89.0.365519083629.issue37765@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3d1c06e8b9eec5fc1ea2ed4dc1ea79c705da8ab8 by Miss Islington (bot) in branch '3.8':
bpo-37765: Add keywords to IDLE tab completions (GH-15138)
https://github.com/python/cpython/commit/3d1c06e8b9eec5fc1ea2ed4dc1ea79c705da8ab8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Thu Jul  9 19:47:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2020 23:47:45 +0000
Subject: [issue37765] IDLE: Include keywords in module-level autocomplete list
In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org>
Message-ID: <1594338465.35.0.302740753304.issue37765@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PR 15138 always adds keywords to the big list for the current module.  They are also normally present in the small list, when it only excludes '_' names.  But if the module being edited contains '__all__', the small list, which is the first list presented, is currently just __all__.  This excludes builtins and now keywords and possibly non-_ names defined in the module.  I think this restriction is a mistake; __all__ defines a limited external view of the module.  It is not intended to restrict the names used in the module.  I will remove the restriction (and a crash bug it contains) in a partly completed PR for #37766.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37765>
_______________________________________

From report at bugs.python.org  Thu Jul  9 19:51:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2020 23:51:51 +0000
Subject: [issue27609] IDLE completions: format, factor, and fix
In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za>
Message-ID: <1594338711.1.0.0528601802851.issue27609@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The removed post duplicates the content of #37766.  Another bug is reported and will be fixed there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27609>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:06:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jul 2020 00:06:53 +0000
Subject: [issue37766] IDLE autocomplete: revise fetch_completions, add htest
In-Reply-To: <1565037293.97.0.42173755359.issue37766@roundup.psfhosted.org>
Message-ID: <1594339613.65.0.564698684432.issue37766@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The attached tem4.py validates a refactoring of the mode ATTRS, what '' computation of bigl.  The removal of dict 'namespace' invalidates 

                    if "__all__" in bigl:
                        smalll = sorted(eval("__all__", namespace))

However, this small branch should be removed as explained in msg373432.  The removal will also fix an IDLE execution process crash resulting from a user bug.  Given "__all__ = [modname], Show Completions results in
TypeError: cannot pickle 'module' object
and a crash restart.

After "import modname", "modname." wait or Show Completions crashes due to 
                        if "__all__" in bigl:
                            smalll = sorted(entity.__all__)
Since this is needed, the fix is to filter entity.__all__.

----------
Added file: https://bugs.python.org/file49311/tem4.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37766>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:20:24 2020
From: report at bugs.python.org (Christoph Anton Mitterer)
Date: Fri, 10 Jul 2020 00:20:24 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1594340424.12.0.451013021796.issue11354@roundup.psfhosted.org>


Christoph Anton Mitterer <calestyo at scientia.org> added the comment:

Next to code readability, there's IMO one could reason to properly support this would be a clean and easy way to get proper help strings for such options.

Of course I can do something like:
parser = argparse.ArgumentParser()
parser.add_argument("--foo", nargs="+", help="Mae govannen", metavar=("bar", "baz"))
args = parser.parse_args()

and later check that, say, only 2 arguments are allowed.

But the help text will be an ugly:
>$ python3 f.py --help
>usage: f.py [-h] [--foo bar [baz ...]]
>
>optional arguments:
>  -h, --help           show this help message and exit
>  --foo bar [baz ...]  Mae govannen

indicating that >1 options were allowed.

----------
nosy: +calestyo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:36:42 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 10 Jul 2020 00:36:42 +0000
Subject: [issue23802] patch: __deepcopy__ memo dict argument usage
In-Reply-To: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>
Message-ID: <1594341402.04.0.242031345971.issue23802@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 3cbade7d309ab1ea97ec286d19d506df30bd1ab7 by Joannah Nanjekye in branch 'master':
bpo-23802: patch: __deepcopy__ memo dict argument usage (GH-21326)
https://github.com/python/cpython/commit/3cbade7d309ab1ea97ec286d19d506df30bd1ab7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23802>
_______________________________________

From report at bugs.python.org  Thu Jul  9 23:01:12 2020
From: report at bugs.python.org (paul j3)
Date: Fri, 10 Jul 2020 03:01:12 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
In-Reply-To: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>
Message-ID: <1594350072.42.0.726759224647.issue41255@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

I didn't pay attention to the patch that added this "exit_on_error" parameter.  So I don't know exactly what error handling it was supposed to handle or why.  But given the location of the code change, it does not handle every possible error.

Specifically it's  in parser.parse_known_args() where it calls _parse_known_args().  With this parameter True, a argparse.ArgumentError is caught and converted to parse.error() call.  That's the original behavior.

With False, there's no special handling for ArgumentError.  Catching that is left to the developer, as illustrated in the docs.

In the documented example, it's a 'type' error. 'choices' would also behave this way. 'nargs' errors also.  But not all errors are handled like this.

Inside _parse_known_args(), `self.error()` is called several times, once for 'required' arguments failure, and for a required mutually_exclusive_group error.  I count 9 self.error() calls; exit_on_error only changes one of those.

The error highlighted in this issue is called in parser.parse_args().  This calls parse_known_args(), and raises an error if there are 'extras', unrecognized strings.

So clearly the new docs is is describing this new parameter in overly broad terms.  It only changes the handling of a subset of parser.error() calls.  Off hand I can't think of clean way of refining the description without getting overly technical about the error handling.

Developers already had the documented option of changing the parse.error() and parse.exit() methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Thu Jul  9 23:25:42 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Fri, 10 Jul 2020 03:25:42 +0000
Subject: [issue37894] [win] shutil.which can not find the path if 'cmd'
 include directory path and not include extension name
In-Reply-To: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org>
Message-ID: <1594351542.61.0.818140751177.issue37894@roundup.psfhosted.org>


Wansoo Kim <rladhkstn8 at gmail.com> added the comment:

Can I solve this problem?

----------
nosy: +ys19991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37894>
_______________________________________

From report at bugs.python.org  Thu Jul  9 23:59:03 2020
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 10 Jul 2020 03:59:03 +0000
Subject: [issue41254] Add to/from string methods to datetime.timedelta
In-Reply-To: <1594277218.28.0.16887324914.issue41254@roundup.psfhosted.org>
Message-ID: <1594353543.68.0.726172426218.issue41254@roundup.psfhosted.org>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I think the lack sub second parts in these formats is a disadvantage.
There's a merit in using a standard but IMO it's more natural to write someting like "2s" in a configuration value than "P2S" which is more cryptic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41254>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:39:09 2020
From: report at bugs.python.org (paul j3)
Date: Fri, 10 Jul 2020 04:39:09 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
In-Reply-To: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>
Message-ID: <1594355949.66.0.339098742914.issue41255@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

For custom handling of unrecognized arguments, use parser_known_args().  You don't need this new parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Fri Jul 10 02:38:12 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Fri, 10 Jul 2020 06:38:12 +0000
Subject: [issue37578] Change Glob: Allow Recursion for Hidden Files
In-Reply-To: <1562984633.23.0.0355519865943.issue37578@roundup.psfhosted.org>
Message-ID: <1594363092.62.0.551694473026.issue37578@roundup.psfhosted.org>


Wansoo Kim <rladhkstn8 at gmail.com> added the comment:

Can you reproduce this bug? I was able to find the hidden file by recursive search by excuting the code below.

```
from glob import glob

hidden = glob('**/.*')

print(hidden)
```

----------
nosy: +ys19991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37578>
_______________________________________

From report at bugs.python.org  Fri Jul 10 02:46:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 06:46:35 +0000
Subject: [issue41263] Convert code.__new__ to Argument Clinic
In-Reply-To: <1594326069.58.0.0732196430915.issue41263@roundup.psfhosted.org>
Message-ID: <1594363595.12.0.148132234355.issue41263@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20573
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21426

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41263>
_______________________________________

From report at bugs.python.org  Fri Jul 10 02:55:52 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Fri, 10 Jul 2020 06:55:52 +0000
Subject: [issue41264] Do not use the name of the built-in function as a
 variable.
Message-ID: <1594364152.69.0.806564284031.issue41264@roundup.psfhosted.org>


New submission from Wansoo Kim <rladhkstn8 at gmail.com>:

Using the name of the built-in function as a variable can cause unexpected problems.

```
# example

type = 'Hello'

...

type('Happy')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object is not callable

```

You can go back without any problems right now, but you may have problems later when others make corrections.

This code can be returned without any problems right now, but it may cause problems later when others make a change.

In the Lib/xml/etree function/_default, assign a value for the type.

```
...

type = self._doctype[1]
if type == "PUBLIC" and n == 4:
    name, type, pubis, system = self._doctype

...
```

----------
messages: 373442
nosy: ys19991
priority: normal
severity: normal
status: open
title: Do not use the name of the built-in function as a variable.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41264>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:00:48 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Fri, 10 Jul 2020 07:00:48 +0000
Subject: [issue41264] Do not use the name of the built-in function as a
 variable.
In-Reply-To: <1594364152.69.0.806564284031.issue41264@roundup.psfhosted.org>
Message-ID: <1594364448.83.0.92874086459.issue41264@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
pull_requests: +20574
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21427

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41264>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:08:22 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Fri, 10 Jul 2020 07:08:22 +0000
Subject: [issue41264] Do not use the name of the built-in function as a
 variable.
In-Reply-To: <1594364152.69.0.806564284031.issue41264@roundup.psfhosted.org>
Message-ID: <1594364902.77.0.101564639657.issue41264@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
pull_requests: +20575
pull_request: https://github.com/python/cpython/pull/21428

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41264>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:12:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 07:12:10 +0000
Subject: [issue41263] Convert code.__new__ to Argument Clinic
In-Reply-To: <1594326069.58.0.0732196430915.issue41263@roundup.psfhosted.org>
Message-ID: <1594365130.97.0.0134181983941.issue41263@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0f9aa47babbfbecc5ef500fb0feae755230ec3c0 by Serhiy Storchaka in branch 'master':
bpo-41263: Convert code.__new__ to Argument Clinic (GH-21426)
https://github.com/python/cpython/commit/0f9aa47babbfbecc5ef500fb0feae755230ec3c0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41263>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:17:22 2020
From: report at bugs.python.org (David Halter)
Date: Fri, 10 Jul 2020 07:17:22 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594365442.46.0.120312664478.issue40360@roundup.psfhosted.org>


David Halter <davidhalter88 at gmail.com> added the comment:

I'm the maintainer of parso. Feel free to addd me to the Nosy List if we have these discussions in the future.

Parso is indeed a lib2to3 fork with error recovery, round tripping and incremental parsing as its features. Most pgen2 code has been rewritten since for various reasons, but it's essentially still LL(1). We're currently trying to think how to proceed with Non-LL(1). For very simple cases a few hacks could suffice, but for larger stuff we will probably need to implement some form of PEG parsing.

I'm mostly worried about incremental parsing breaking if we replace the PEG parser, not about writing the PEG parser. But I guess we'll find a way, because I don't want to abandon Jedi (which depends on parso).

----------
nosy: +davidhalter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:23:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 07:23:20 +0000
Subject: [issue41263] Convert code.__new__ to Argument Clinic
In-Reply-To: <1594326069.58.0.0732196430915.issue41263@roundup.psfhosted.org>
Message-ID: <1594365800.41.0.878746539657.issue41263@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41263>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:36:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 07:36:25 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1594366585.24.0.353239503982.issue36346@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +20576
pull_request: https://github.com/python/cpython/pull/21429

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:38:06 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 07:38:06 +0000
Subject: [issue30044] shutil.copystat should (allow to) copy ownership,
 and other attributes
In-Reply-To: <1491925353.8.0.782070431072.issue30044@psf.upfronthosting.co.za>
Message-ID: <1594366686.61.0.280448265023.issue30044@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

POSIX ACLs and SELinux context information are stored in extended file attributes. The information is copied from source to destination. POSIX ACLs are stored in xattr "system.posix_acl_access" and SELinux context in xattr "security.selinux".

----------
keywords: +easy
nosy: +christian.heimes
stage:  -> needs patch
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30044>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:38:58 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 07:38:58 +0000
Subject: [issue24163] shutil.copystat fails when attribute security.selinux is
 present
In-Reply-To: <1431311142.46.0.816679575818.issue24163@psf.upfronthosting.co.za>
Message-ID: <1594366738.7.0.125233636778.issue24163@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm marking this as duplicate of #38893 because the newer bug contains more information.

----------
nosy: +christian.heimes
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> broken container/selinux integration

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24163>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:42:37 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 07:42:37 +0000
Subject: [issue20257] test_socket fails if using tipc module and SELinux
 enabled
In-Reply-To: <1389692362.24.0.80510230142.issue20257@psf.upfronthosting.co.za>
Message-ID: <1594366957.12.0.942748909568.issue20257@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The bug report is over six years ago and I haven't seen any TIPC related issues for a while. The test suite has additional guards to skip TIPC tests when the Kernel module is not loaded.

----------
nosy: +christian.heimes
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20257>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:43:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 07:43:18 +0000
Subject: [issue41264] Do not use the name of the built-in function as a
 variable.
In-Reply-To: <1594364152.69.0.806564284031.issue41264@roundup.psfhosted.org>
Message-ID: <1594366998.45.0.79279130559.issue41264@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

We usually do not accept pure cosmetic changes.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41264>
_______________________________________

From report at bugs.python.org  Fri Jul 10 03:49:13 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Fri, 10 Jul 2020 07:49:13 +0000
Subject: [issue40982] copytree example in shutil
In-Reply-To: <1592212728.34.0.101904144419.issue40982@roundup.psfhosted.org>
Message-ID: <1594367353.72.0.549349092666.issue40982@roundup.psfhosted.org>


Wansoo Kim <rladhkstn8 at gmail.com> added the comment:

Can I solve this issue?

----------
nosy: +ys19991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40982>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:17:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 08:17:25 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1594369045.93.0.20083698633.issue36346@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d878349bac6c154fbfeffe7d4b38e2ddb833f135 by Serhiy Storchaka in branch 'master':
bpo-36346: Do not use legacy Unicode C API in ctypes. (#21429)
https://github.com/python/cpython/commit/d878349bac6c154fbfeffe7d4b38e2ddb833f135


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:21:49 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 08:21:49 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1594369309.3.0.157982300515.issue38893@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The issue came up at $WORK now. Core utils like copy command ignore "security.selinux" xattr unless the user explicitly asks to preserve the security context, see

https://github.com/coreutils/coreutils/blob/6a3d2883fed853ee01079477020091068074e12d/src/copy.c#L867-L891
https://github.com/philips/attr/blob/1cc88bd4c17ef99ace22c8be362d513f155b1387/libattr/attr_copy_fd.c#L109-L111

_copyxattr() ignores most errnos that are listed in the man page of setxattr(2) but not EACCES. The man page of setxattr(2) also points to stat(2) which lists EACCES as possible errno.

I see three simple and two more complicated solutions:

1) ignore EACCES completely
2) ignore EACCES for "security.selinux"
3) ignore EACCES for "security.*"
4) provide a callback similar to the check() callback in libattr's attr_copy_fd(). Only copy an xattr when the callback is not set or returns True.
5) provide an extra option to skip security context

Related: https://bugs.python.org/issue24564#msg351555 also suggests that copyxattr should ignore ENOSYS in listxattr. Some file systems (NFS?) seem to lack xattr.

Hynek, you implemented most of copyxattr in 0beab058dd4 back in 2013. What's your opinion?

----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:22:12 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 08:22:12 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1594369332.79.0.146281727131.issue38893@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> christian.heimes
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:35:35 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 08:35:35 +0000
Subject: [issue26328] shutil._copyxattr() function shouldn't fail if setting
 security.selinux xattr fails
In-Reply-To: <1455109424.72.0.659631056233.issue26328@psf.upfronthosting.co.za>
Message-ID: <1594370135.27.0.675272876138.issue26328@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm marking this as duplicate of #38893. The other bug has more information.

----------
nosy: +christian.heimes
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> broken container/selinux integration

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26328>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:38:07 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 08:38:07 +0000
Subject: [issue35350] importing "ctypes" immediately causes a segmentation
 fault
In-Reply-To: <1543504667.76.0.788709270274.issue35350@psf.upfronthosting.co.za>
Message-ID: <1594370287.95.0.144549354675.issue35350@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Python 2.7 has reached its end of lifetime. Please re-open the bug if you can reproduce the issue on Python 3.8 or newer.

----------
nosy: +christian.heimes
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35350>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:41:23 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Jul 2020 08:41:23 +0000
Subject: [issue41145] EmailMessage.as_string is altering the message state and
 actually fix bugs
In-Reply-To: <1593337413.31.0.292797380525.issue41145@roundup.psfhosted.org>
Message-ID: <1594370483.63.0.101432132803.issue41145@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
components: +email
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41145>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:43:09 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 10 Jul 2020 08:43:09 +0000
Subject: [issue41075] Make support of navigating through prev. commands in
 IDLE more conspicuous
In-Reply-To: <1592824587.6.0.226335506835.issue41075@roundup.psfhosted.org>
Message-ID: <1594370589.9.0.633313622287.issue41075@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41075>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:45:33 2020
From: report at bugs.python.org (Ma Lin)
Date: Fri, 10 Jul 2020 08:45:33 +0000
Subject: [issue41265] lzma/bz2 module: inefficient buffer growth algorithm
Message-ID: <1594370733.96.0.701626485898.issue41265@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

lzma/bz2 modules are using the same buffer growth algorithm: [1][2]

    newsize = size + (size >> 3) + 6;
    
lzma/bz2 modules' default output buffer is 8192 bytes [3][4], so the growth step is below.

For many cases, maybe the buffer is resized too many times.
Is it possible to design a new growth algorithm that grows faster when the size is not very large.

  1: 8,196 bytes
  2: 9,226 bytes
  3: 10,385 bytes
  4: 11,689 bytes
  5: 13,156 bytes
  6: 14,806 bytes
  7: 16,662 bytes
  8: 18,750 bytes
  9: 21,099 bytes
 10: 23,742 bytes
 11: 26,715 bytes
 12: 30,060 bytes
 13: 33,823 bytes
 14: 38,056 bytes
 15: 42,819 bytes
 16: 48,177 bytes
 17: 54,205 bytes
 18: 60,986 bytes
 19: 68,615 bytes
 20: 77,197 bytes
 21: 86,852 bytes
 22: 97,714 bytes
 23: 109,934 bytes
 24: 123,681 bytes
 25: 139,147 bytes
 26: 156,546 bytes
 27: 176,120 bytes
 28: 198,141 bytes
 29: 222,914 bytes
 30: 250,784 bytes
 31: 282,138 bytes
 32: 317,411 bytes
 33: 357,093 bytes
 34: 401,735 bytes
 35: 451,957 bytes
 36: 508,457 bytes
 37: 572,020 bytes
 38: 643,528 bytes
 39: 723,975 bytes
 40: 814,477 bytes
 41: 916,292 bytes
 42: 1,030,834 bytes
 43: 1,159,694 bytes
 44: 1,304,661 bytes
 45: 1,467,749 bytes
 46: 1,651,223 bytes
 47: 1,857,631 bytes
 48: 2,089,840 bytes
 49: 2,351,076 bytes
 50: 2,644,966 bytes
 51: 2,975,592 bytes
 52: 3,347,547 bytes
 53: 3,765,996 bytes
 54: 4,236,751 bytes
 55: 4,766,350 bytes
 56: 5,362,149 bytes
 57: 6,032,423 bytes
 58: 6,786,481 bytes
 59: 7,634,797 bytes
 60: 8,589,152 bytes
 61: 9,662,802 bytes
 62: 10,870,658 bytes
 63: 12,229,496 bytes
 64: 13,758,189 bytes
 65: 15,477,968 bytes
 66: 17,412,720 bytes
 67: 19,589,316 bytes
 68: 22,037,986 bytes
 69: 24,792,740 bytes
 70: 27,891,838 bytes
 71: 31,378,323 bytes
 72: 35,300,619 bytes
 73: 39,713,202 bytes
 74: 44,677,358 bytes
 75: 50,262,033 bytes
 76: 56,544,793 bytes
 77: 63,612,898 bytes
 78: 71,564,516 bytes
 79: 80,510,086 bytes
 80: 90,573,852 bytes
 81: 101,895,589 bytes
 82: 114,632,543 bytes
 83: 128,961,616 bytes
 84: 145,081,824 bytes
 85: 163,217,058 bytes
 86: 183,619,196 bytes
 87: 206,571,601 bytes
 88: 232,393,057 bytes
 89: 261,442,195 bytes
 90: 294,122,475 bytes
 91: 330,887,790 bytes
 92: 372,248,769 bytes
 93: 418,779,871 bytes
 94: 471,127,360 bytes
 95: 530,018,286 bytes
 96: 596,270,577 bytes
 97: 670,804,405 bytes
 98: 754,654,961 bytes
 99: 848,986,837 bytes
100: 955,110,197 bytes

[1] lzma buffer growth algorithm:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/_lzmamodule.c#L133

[2] bz2 buffer growth algorithm:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/_bz2module.c#L121

[3] lzma default buffer size:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/_lzmamodule.c#L124

[4] bz2 default buffer size:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/_bz2module.c#L109

----------
components: Library (Lib)
messages: 373454
nosy: malin
priority: normal
severity: normal
status: open
title: lzma/bz2 module: inefficient buffer growth algorithm
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41265>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:49:56 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 10 Jul 2020 08:49:56 +0000
Subject: [issue41266] Wrong hint when class methods and builtins named same
Message-ID: <1594370995.93.0.883531134582.issue41266@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

There is a function hex(number, /), and float objects have a method hex().
When something like 1.3.hex( is typed, the yellow box's first line contains hex(number, /). But the method is actually hex(), no arguments. It confuses users.
And when 1.3.list( is typed, there isn't a list() method in floats, but the hint still pops up and shows the __doc__ for list(iterable=(), /).

----------
assignee: terry.reedy
components: IDLE
messages: 373455
nosy: terry.reedy, wyz23x2
priority: normal
severity: normal
status: open
title: Wrong hint when class methods and builtins named same
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41266>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:09:51 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 10 Jul 2020 09:09:51 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1594372191.68.0.57450530162.issue38893@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +20577
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21430

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:57:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jul 2020 09:57:24 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594375044.71.0.318124052546.issue41261@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, I can reproduce the crash on the 3.9 branch using: ./python repro.py.

The first problem is that astmodule_clear() doesn't reset the initiallized member: add "state->initialized = 0;".

The _ast module is special. Not only it has regular module function which access the module state, it also has 3 functions in C APIs which are called directly:

* PyAST_Check()
* PyAST_mod2obj()
* PyAST_obj2mod()

These functions require to have access to the _ast module. In Python 3.9, I chose to use a global state, as it was done in Python 3.8.

If sys.modules['_ast'] is cleared and then _ast is imported again, _PyState_AddModule() is called to store the new _ast module instance which calls astmodule_clear() on the old module instance.

The problem is that when astmodule_clear() is called, the new instance is already created and so exposes the "old" _ast.AST type.

1) import _ast: call init_types() which creates AST type #1
2) del sys.modules['_ast]
3) import _ast: create a new module which exposes AST type #1
3) import _ast: also clears the old module (_PyState_AddModule()) which calls astmodule_clear()
4) Calling PyAST_Check() calls init_types() which creates AST type #2: PyAST_Check() returns false, since AST type #1 and AST type #2 are different

--

In the master branch, I modified PyAST_Check(), PyAST_mod2obj() and PyAST_obj2mod() to import the _ast module and get the state from the module. The state is not global in master.

For 3.9, I'm not sure what is the best option:

* Backport master changes (not well tested yet, but is it worse than this known crash?)
* Never clear the state: leak references at Python exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:58:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jul 2020 09:58:02 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594375082.97.0.310054525142.issue41261@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This bug is a follow-up of bpo-41194: "Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:59:28 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jul 2020 09:59:28 +0000
Subject: [issue41175] Static analysis issues reported by GCC 10
In-Reply-To: <1593540409.36.0.220720333967.issue41175@roundup.psfhosted.org>
Message-ID: <1594375168.9.0.519405347619.issue41175@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20578
pull_request: https://github.com/python/cpython/pull/21431

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41175>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:59:55 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jul 2020 09:59:55 +0000
Subject: [issue41175] Static analysis issues reported by GCC 10
In-Reply-To: <1593540409.36.0.220720333967.issue41175@roundup.psfhosted.org>
Message-ID: <1594375195.97.0.560753072265.issue41175@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20579
pull_request: https://github.com/python/cpython/pull/21432

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41175>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:16:18 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jul 2020 10:16:18 +0000
Subject: [issue41175] Static analysis issues reported by GCC 10
In-Reply-To: <1593540409.36.0.220720333967.issue41175@roundup.psfhosted.org>
Message-ID: <1594376178.11.0.97222077044.issue41175@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 33672c019179be279ae979f709c974593fbbbe84 by Miss Islington (bot) in branch '3.8':
bpo-41175: Guard against a NULL pointer dereference within bytearrayobject (GH-21240)
https://github.com/python/cpython/commit/33672c019179be279ae979f709c974593fbbbe84


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41175>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:17:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jul 2020 10:17:32 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1594376252.99.0.410009671089.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +20580
pull_request: https://github.com/python/cpython/pull/21433

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:18:54 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jul 2020 10:18:54 +0000
Subject: [issue41175] Static analysis issues reported by GCC 10
In-Reply-To: <1593540409.36.0.220720333967.issue41175@roundup.psfhosted.org>
Message-ID: <1594376334.05.0.542661495674.issue41175@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 51b36ed96d29c9440fbca18fb0c9e3087f763da5 by Miss Islington (bot) in branch '3.9':
bpo-41175: Guard against a NULL pointer dereference within bytearrayobject (GH-21240)
https://github.com/python/cpython/commit/51b36ed96d29c9440fbca18fb0c9e3087f763da5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41175>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:38:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jul 2020 10:38:18 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594377498.52.0.380624458884.issue41261@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:40:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jul 2020 10:40:54 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1594377654.61.0.238883802589.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8182cc2e68a3c6ea5d5342fed3f1c76b0521fbc1 by Victor Stinner in branch 'master':
bpo-39573: Use the Py_TYPE() macro (GH-21433)
https://github.com/python/cpython/commit/8182cc2e68a3c6ea5d5342fed3f1c76b0521fbc1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:43:52 2020
From: report at bugs.python.org (owais)
Date: Fri, 10 Jul 2020 10:43:52 +0000
Subject: [issue41267] Attribute error: Pandas module doesn't have 'Plotting'
 attribute
Message-ID: <1594377832.45.0.135300974033.issue41267@roundup.psfhosted.org>


New submission from owais <owaisali358 at gmail.com>:

Hello... I am deploying a django application over the AWS Cloud Server EC2 windows instance having AMD64 architecture. I have installed python 3.7.6 over the server and install all modules (numpy pandas matplotlib django etc) using pip. I have set the sqlite server on AWS. I changed the path variables from local dir to server dir and also change the database server name. but When I run the server from cmd by typing "python manage.py runserver" I am facing an issue/error that says pandas module does not have plotting module. Whereas I checked in site-pakages under pandas folder, there is a subfolder named as 'plotting'. I have again installed the newer version of pip by upgrade pip command then install the pandas but no success acheived. Kindly help me out I am attaching 2 pictures, one is the error and other is project directory where all scripts are present.

----------
components: Windows
files: Error.zip
messages: 373461
nosy: owais.ali, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Attribute error: Pandas module doesn't have 'Plotting' attribute
type: performance
versions: Python 3.7
Added file: https://bugs.python.org/file49312/Error.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41267>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:49:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Jul 2020 10:49:06 +0000
Subject: [issue41267] Attribute error: Pandas module doesn't have 'Plotting'
 attribute
In-Reply-To: <1594377832.45.0.135300974033.issue41267@roundup.psfhosted.org>
Message-ID: <1594378146.79.0.267243933839.issue41267@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This bug tracker is for reporting bugs in python, not for getting help using python.

I suggest asking for help on the python-list mailing list: https://mail.python.org/mailman/listinfo/python-list

Or, since this sounds like you're having problems with pandas, perhaps a pandas-specific forum would be better. I'm not familiar with the pandas community to know where you should look, sorry.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41267>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:56:27 2020
From: report at bugs.python.org (Rishi)
Date: Fri, 10 Jul 2020 10:56:27 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594378587.78.0.122672015284.issue39017@roundup.psfhosted.org>


Change by Rishi <rishi93dev at gmail.com>:


----------
nosy: +rishi93

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Fri Jul 10 07:26:20 2020
From: report at bugs.python.org (tomaszdrozdz)
Date: Fri, 10 Jul 2020 11:26:20 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594380380.86.0.511194281299.issue41202@roundup.psfhosted.org>


tomaszdrozdz <tomasz.drozdz.1 at protonmail.com> added the comment:

I just wanted to call  

    def main():
        asyncio.run(...)

But I can go with Your aproach.  
Thanks for discusion.  

Should I set status for this issue for closed with resolution rejected ?  

Should I delete branch on my forked git repo ?
Can I delete my forked git repo ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Fri Jul 10 08:47:44 2020
From: report at bugs.python.org (Hugo van Kemenade)
Date: Fri, 10 Jul 2020 12:47:44 +0000
Subject: [issue41268] 3.9-dev regression? TypeError: exec_module() missing 1
 required positional argument: 'module'
Message-ID: <1594385264.3.0.0834998947861.issue41268@roundup.psfhosted.org>


New submission from Hugo van Kemenade <hugovk+python at gmail.com>:

For the past 3 months we've been testing Pillow on Travis CI using 3.9-dev, which Travis builds nightly from the 3.9 branch.

Two days ago the 3.9-dev build passed, but it failed yesterday with the same Pillow commit, and all subsequent builds.

* Last pass: https://travis-ci.org/github/python-pillow/Pillow/jobs/706015838
* First fail: https://travis-ci.org/github/hugovk/Pillow/jobs/706476038

Diffing the logs, here's the CPython commits for each:

platform     linux 3.9.0b4+ (heads/3.9:edeaf61, Jul  7 2020, 06:29:52)
platform     linux 3.9.0b4+ (heads/3.9:1d1c574, Jul  8 2020, 07:05:21)

Diff of those commits:

https://github.com/python/cpython/compare/edeaf61b6827ab3a8673aff1fb7717917f08f003..1d1c5743400bdf384ec83eb6ba5b39a355d121e3

It's also failing with the most recent:

platform     linux 3.9.0b4+ (heads/3.9:e689789, Jul  9 2020, 07:57:24)

I didn't see anything obvious to cause it, so thought I'd better report it here to be on the safe side.

Our tracking issue: https://github.com/python-pillow/Pillow/issues/4769

Here's the traceback:

Finished processing dependencies for Pillow==7.3.0.dev0
python3 selftest.py
Traceback (most recent call last):
  File "/home/travis/build/hugovk/Pillow/selftest.py", line 6, in <module>
    from PIL import Image, features
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 627, in _load_backward_compatible
  File "<frozen zipimport>", line 259, in load_module
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/Image.py", line 94, in <module>
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 627, in _load_backward_compatible
  File "<frozen zipimport>", line 259, in load_module
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/_imaging.py", line 8, in <module>
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/_imaging.py", line 7, in __bootstrap__
TypeError: exec_module() missing 1 required positional argument: 'module'
Makefile:59: recipe for target 'install-coverage' failed
make: *** [install-coverage] Error 1
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 495, in _importconftest
    return self._conftestpath2mod[key]
KeyError: PosixPath('/home/travis/build/hugovk/Pillow/conftest.py')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/opt/python/3.9-dev/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/python/3.9-dev/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pytest/__main__.py", line 7, in <module>
    raise SystemExit(pytest.main())
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 105, in main
    config = _prepareconfig(args, plugins)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 257, in _prepareconfig
    return pluginmanager.hook.pytest_cmdline_parse(
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/hooks.py", line 286, in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/manager.py", line 93, in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/manager.py", line 84, in <lambda>
    self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/callers.py", line 203, in _multicall
    gen.send(outcome)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/helpconfig.py", line 90, in pytest_cmdline_parse
    config = outcome.get_result()
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/callers.py", line 187, in _multicall
    res = hook_impl.function(*args)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 836, in pytest_cmdline_parse
    self.parse(args)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 1044, in parse
    self._preparse(args, addopts=addopts)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 1001, in _preparse
    self.hook.pytest_load_initial_conftests(
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/hooks.py", line 286, in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/manager.py", line 93, in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/manager.py", line 84, in <lambda>
    self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/callers.py", line 208, in _multicall
    return outcome.get_result()
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/pluggy/callers.py", line 187, in _multicall
    res = hook_impl.function(*args)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 899, in pytest_load_initial_conftests
    self.pluginmanager._set_initial_conftests(early_config.known_args_namespace)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 441, in _set_initial_conftests
    self._try_load_conftest(anchor)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 447, in _try_load_conftest
    self._getconftestmodules(anchor)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 473, in _getconftestmodules
    mod = self._importconftest(conftestpath)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 520, in _importconftest
    self.consider_conftest(mod)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 575, in consider_conftest
    self.register(conftestmodule, name=conftestmodule.__file__)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 386, in register
    self.consider_module(plugin)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 581, in consider_module
    self._import_plugin_specs(getattr(mod, "pytest_plugins", []))
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 586, in _import_plugin_specs
    self.import_plugin(import_spec)
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/config/__init__.py", line 613, in import_plugin
    __import__(importspec)
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/_pytest/assertion/rewrite.py", line 152, in exec_module
    exec(co, module.__dict__)
  File "/home/travis/build/hugovk/Pillow/Tests/helper.py", line 14, in <module>
    from PIL import Image, ImageMath, features
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 627, in _load_backward_compatible
  File "<frozen zipimport>", line 259, in load_module
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/Image.py", line 94, in <module>
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 627, in _load_backward_compatible
  File "<frozen zipimport>", line 259, in load_module
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/_imaging.py", line 8, in <module>
  File "/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/_imaging.py", line 7, in __bootstrap__
TypeError: exec_module() missing 1 required positional argument: 'module'

----------
messages: 373464
nosy: hugovk
priority: normal
severity: normal
status: open
title: 3.9-dev regression? TypeError: exec_module() missing 1 required positional argument: 'module'
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41268>
_______________________________________

From report at bugs.python.org  Fri Jul 10 09:43:09 2020
From: report at bugs.python.org (Ivan)
Date: Fri, 10 Jul 2020 13:43:09 +0000
Subject: [issue41269] Wrong subtraction calculations
Message-ID: <1594388589.34.0.510717006355.issue41269@roundup.psfhosted.org>


New submission from Ivan <ivan.babic.zg at gmail.com>:

I've started to learn python and tried command:
print(-2.989 + 2)
it gives me result of -0.9889999999999999
same error can be observed with numbers from 4 and below like:
print(-2.989 + 4)
1.0110000000000001

print(-2.989 + 3)
0.01100000000000012

print(-2.989 + 1)
-1.9889999999999999

Numbers above 4 seam to work fine

----------
components: Windows
files: python error.jpg
messages: 373465
nosy: Svabo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Wrong subtraction calculations
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49313/python error.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41269>
_______________________________________

From report at bugs.python.org  Fri Jul 10 09:54:39 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 10 Jul 2020 13:54:39 +0000
Subject: [issue41269] Wrong subtraction calculations
In-Reply-To: <1594388589.34.0.510717006355.issue41269@roundup.psfhosted.org>
Message-ID: <1594389279.55.0.21477968475.issue41269@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report. This isn't a Python bug, but a common issue when working with floating-point numbers.

I recommend taking a look at this section of the tutorial for more information: https://docs.python.org/3.8/tutorial/floatingpoint.html

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41269>
_______________________________________

From report at bugs.python.org  Fri Jul 10 09:58:42 2020
From: report at bugs.python.org (Seth Sims)
Date: Fri, 10 Jul 2020 13:58:42 +0000
Subject: [issue41270] NamedTemporaryFile is not its own iterator.
Message-ID: <1594389522.96.0.51886326593.issue41270@roundup.psfhosted.org>


New submission from Seth Sims <seth.sims at gmail.com>:

_TemporaryFileWrapper does not proxy __next__ to the underlying file object. There was a discussion on the mailing list in 2016 mentioning this, however it seems it was dropped without a consensus. Biopython encountered this issue (referenced below) and we agree it violates our assumptions about how the NamedTemporaryFile should work. I think it would be fairly trivial to fix by just returning `self.file.readline()`

mailing list thread: https://mail.python.org/pipermail/python-list/2016-July/862590.html

biopython discussion: https://github.com/biopython/biopython/pull/3031

----------
components: Library (Lib)
messages: 373467
nosy: Seth Sims
priority: normal
severity: normal
status: open
title: NamedTemporaryFile is not its own iterator.
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/issue41270>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:00:53 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jul 2020 14:00:53 +0000
Subject: [issue41270] NamedTemporaryFile is not its own iterator.
In-Reply-To: <1594389522.96.0.51886326593.issue41270@roundup.psfhosted.org>
Message-ID: <1594389653.84.0.408306589457.issue41270@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20581
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21434

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41270>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:13:26 2020
From: report at bugs.python.org (Rishi)
Date: Fri, 10 Jul 2020 14:13:26 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594390406.06.0.211614226776.issue39017@roundup.psfhosted.org>


Rishi <rishi93dev at gmail.com> added the comment:

Hi ! I would like to start contributing to CPython. Can I start working on this issue ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:45:31 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jul 2020 14:45:31 +0000
Subject: [issue41268] 3.9-dev regression? TypeError: exec_module() missing 1
 required positional argument: 'module'
In-Reply-To: <1594385264.3.0.0834998947861.issue41268@roundup.psfhosted.org>
Message-ID: <1594392331.76.0.574577487578.issue41268@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41268>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:45:47 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jul 2020 15:45:47 +0000
Subject: [issue41227] minor typo in asyncio transport protocol
In-Reply-To: <1594092816.12.0.525496493671.issue41227@roundup.psfhosted.org>
Message-ID: <1594395947.81.0.74881059121.issue41227@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +20582
pull_request: https://github.com/python/cpython/pull/21435

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41227>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:46:11 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jul 2020 15:46:11 +0000
Subject: [issue41227] minor typo in asyncio transport protocol
In-Reply-To: <1594092816.12.0.525496493671.issue41227@roundup.psfhosted.org>
Message-ID: <1594395971.19.0.825388801469.issue41227@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20583
pull_request: https://github.com/python/cpython/pull/21436

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41227>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:47:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 15:47:51 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1594396071.62.0.905825232028.issue36346@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +20584
pull_request: https://github.com/python/cpython/pull/21437

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:54:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jul 2020 15:54:47 +0000
Subject: [issue41227] minor typo in asyncio transport protocol
In-Reply-To: <1594092816.12.0.525496493671.issue41227@roundup.psfhosted.org>
Message-ID: <1594396487.77.0.0181411391691.issue41227@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Faris for the report and @ys19991 for the patch. Closing this as fixed.

----------
nosy: +xtreak
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41227>
_______________________________________

From report at bugs.python.org  Fri Jul 10 12:41:46 2020
From: report at bugs.python.org (paul j3)
Date: Fri, 10 Jul 2020 16:41:46 +0000
Subject: [issue41255] Argparse.parse_args exits on unrecognized option with
 exit_on_error=False
In-Reply-To: <1594284033.21.0.100091861021.issue41255@roundup.psfhosted.org>
Message-ID: <1594399306.03.0.354942507588.issue41255@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

The docs could change 

"catch errors manually"

to

"catch ArgumentError manually"

But while 'argparse.ArgumentError' is imported, it is not documented. We have to study the code to learn when it is raised.  

Its class def:

    def __init__(self, argument, message):

shows it's tied to a specific 'argument', an Action object.  Most commonly it is produced by reraising a ValueError, TypeError or ArgumentTypeError during the check_values step.

Unrecognized arguments, and missing required arguments errors aren't produced while processing an argument, but rather while checking  things after parsing.  So they can't raise an ArgumentError, and aren't handled by this new parameter.

I found a old issue that discusses this https://bugs.python.org/issue9938,  https://github.com/python/cpython/pull/15362

There wasn't much discussion about the scope of this change, or about the documentation wording.  My only comment was in 2013, https://bugs.python.org/msg192147

Until we iron out the wording I think this patch should be reverted.

While exploring other problems, I thought it would be a good idea of refactor parse_known_args and _parse_known_args.  Specifically I'd move the 'required' testing and self.error() calls out of _parse_known_args, allowing a developer to write their own versions of parse_known_args.  The goal was to make it easier to test for mixes of seen and unseen arguments.  

In light of the current issue, we might want to look into consolidating all (or at least most) of the calls to self.error() in one function.  Until then, the documented idea of modifying the error() method itself is the best user/developer tool, https://docs.python.org/3.10/library/argparse.html#exiting-methods

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41255>
_______________________________________

From report at bugs.python.org  Fri Jul 10 12:44:52 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 10 Jul 2020 16:44:52 +0000
Subject: [issue30044] shutil.copystat should (allow to) copy ownership,
 and other attributes
In-Reply-To: <1491925353.8.0.782070431072.issue30044@psf.upfronthosting.co.za>
Message-ID: <1594399492.14.0.506365067862.issue30044@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In Windows, I wouldn't expect shutil.copy2 to preserve the owner and ACLs. They change whenever a file gets copied via CopyFileExW [1]. Keeping them exactly as in the source file generally requires a privileged backup and restore operation, such as via BackupRead [2] and BackupWrite [3]. Unless the caller has SeRestorePrivilege, the owner can only be set to one of the SIDs in the caller's groups that are flagged as SE_GROUP_OWNER, which is usually just the user's SID or, for an admin, the Administrators SID. Also, for copying the system ACL, adding or removing audit and scoped-policy-identifier entries requires SeSecurityPrivilege.

CopyFileExW copies all data streams in a file, which is typically just the anonymous data stream, but an NTFS/ReFS file can have multiple named data streams. For metadata, it copies the change and modify timestamps (but not the create and access timestamps), file attributes (readonly, hidden, system, archive, temporary, not-content-indexed), extended attributes, and resource attributes [4]. 

Separating this functionality into shutil.copy and shutil.copystat would be fairly involved. These functions could be left as is and just document the discrepancy in shutil.copy2, or new functions could be implemented in the nt or _winapi module to list the data streams in a file and get/set file attributes and system resource attributes. Supporting extended attributes would require the native NT API, and for little benefit since they're mostly used for "$Kernel." prefixed attributes that can only be set by kernel-mode callers such as drivers.

---

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-copyfileexw
[2]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-backupread
[3]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-backupwrite
[4]: Resource attributes are like extended attributes, but a named resource attribute is a tuple of one or more items with a given data type (integer, string, or bytes) that's stored as an entry in the file's system ACL. Keeping them in the SACL allows conditional access/audit entries to reference them in an access check or access audit. Unlike audit entries in the SACL, reading and writing resource attributes doesn't require SeSecurityPrivilege.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30044>
_______________________________________

From report at bugs.python.org  Fri Jul 10 12:58:06 2020
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jul 2020 16:58:06 +0000
Subject: [issue41145] EmailMessage.as_string is altering the message state and
 actually fix bugs
In-Reply-To: <1593337413.31.0.292797380525.issue41145@roundup.psfhosted.org>
Message-ID: <1594400286.36.0.52159805349.issue41145@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The as_strings docs say:

"Flattening the message may trigger changes to the Message if defaults need to be filled in to complete the transformation to a string (for example, MIME boundaries may be generated or modified)."

So, while this is indeed an API design bug, it isn't an actual bug in the code but rather is expected behavior, currently.  The historical reason for this is that the generator code looks at the entire message to make sure the boundary string is unique.  My long term plan for email included plans to rewrite the generator, and I was going to fix this issue at that point.  My life got too busy to be able to continue with email development work, though, so that never happened.

It has been *years* since I've looked at the code.  Thinking about it now, I'm wondering if it would be possible to use a GUID technique to generate the boundary and thus do exactly as you say: have make_alternative (and anything else that causes a boundary to be needed) pre-create the boundary.  That, I think, would mean we wouldn't need to change the generator, even though it would still be doing its (inefficient) check that the boundary was unique.  I'm not sure if it would work, though; it's been too long since I've looked at the relevant code.

----------
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41145>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:01:05 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 10 Jul 2020 17:01:05 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594400465.02.0.395957114027.issue39017@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Absolutely!

But first, you'll need to sign the Contributor License Agreement:

  https://www.python.org/psf/contrib/contrib-form/

Thank you for your help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:43:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 17:43:45 +0000
Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za>
Message-ID: <1594403024.99.0.442934798845.issue20179@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9650fe0197779b4dfded94be111e39c5810f098f by Zackery Spytz in branch 'master':
bpo-20179: Convert the _overlapped module to the Argument Clinic (GH-14275)
https://github.com/python/cpython/commit/9650fe0197779b4dfded94be111e39c5810f098f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20179>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:43:47 2020
From: report at bugs.python.org (David Parks)
Date: Fri, 10 Jul 2020 17:43:47 +0000
Subject: [issue39959] Bug on multiprocessing.shared_memory
In-Reply-To: <1584128583.89.0.486447704556.issue39959@roundup.psfhosted.org>
Message-ID: <1594403027.44.0.61112572436.issue39959@roundup.psfhosted.org>


David Parks <davidparks21 at gmail.com> added the comment:

Having a flag seems like a good solution to me. I've also encountered this issue and posted on stack overflow about it here:

https://stackoverflow.com/questions/62748654/python-3-8-shared-memory-resource-tracker-producing-unexpected-warnings-at-appli

----------
nosy: +davidparks21

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________

From report at bugs.python.org  Fri Jul 10 14:00:46 2020
From: report at bugs.python.org (Peter)
Date: Fri, 10 Jul 2020 18:00:46 +0000
Subject: [issue41270] NamedTemporaryFile is not its own iterator.
In-Reply-To: <1594389522.96.0.51886326593.issue41270@roundup.psfhosted.org>
Message-ID: <1594404046.96.0.696314582794.issue41270@roundup.psfhosted.org>


Change by Peter <p.j.a.cock at googlemail.com>:


----------
nosy: +maubp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41270>
_______________________________________

From report at bugs.python.org  Fri Jul 10 14:49:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 18:49:47 +0000
Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za>
Message-ID: <1594406987.08.0.407886281523.issue20179@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20179>
_______________________________________

From report at bugs.python.org  Fri Jul 10 14:51:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 18:51:04 +0000
Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in
 Modules/_cursesmodule.c
In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za>
Message-ID: <1594407064.21.0.344668450007.issue20171@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20171>
_______________________________________

From report at bugs.python.org  Fri Jul 10 14:57:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jul 2020 18:57:32 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594407452.07.0.186600349309.issue41261@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It would be nice to fix this 3.9 regression before 3.9 final.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 15:17:28 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 10 Jul 2020 19:17:28 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594408648.88.0.977087287428.issue41261@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 15:19:04 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 10 Jul 2020 19:19:04 +0000
Subject: [issue17490] Improve ast.literal_eval test suite coverage
In-Reply-To: <1363746875.32.0.0832947039866.issue17490@psf.upfronthosting.co.za>
Message-ID: <1594408744.31.0.475963384958.issue17490@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17490>
_______________________________________

From report at bugs.python.org  Fri Jul 10 15:54:07 2020
From: report at bugs.python.org (Cooper Lees)
Date: Fri, 10 Jul 2020 19:54:07 +0000
Subject: [issue41271] Add support for io_uring to cpython
Message-ID: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>


New submission from Cooper Lees <me at cooperlees.com>:

Would adding support for io_uring in Linux to stadlib IO and/or asyncio make sense?

More info on io_uring:
- https://kernel.dk/io_uring.pdf
- https://lwn.net/Articles/810414/

----------
components: IO
messages: 373477
nosy: cooperlees
priority: normal
severity: normal
status: open
title: Add support for io_uring to cpython
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Fri Jul 10 16:26:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jul 2020 20:26:13 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1594412773.68.0.309817462578.issue36346@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4c8f09d7cef8c7aa07d5b5232b5b64f63819a743 by Serhiy Storchaka in branch 'master':
bpo-36346: Make using the legacy Unicode C API optional (GH-21437)
https://github.com/python/cpython/commit/4c8f09d7cef8c7aa07d5b5232b5b64f63819a743


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Fri Jul 10 16:44:00 2020
From: report at bugs.python.org (catrudis)
Date: Fri, 10 Jul 2020 20:44:00 +0000
Subject: [issue41272] New clause in FOR and WHILE instead of ELSE
Message-ID: <1594413840.56.0.248219439277.issue41272@roundup.psfhosted.org>


New submission from catrudis <ar12wtz at gmail.com>:

ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead:

if COND:
  ...
[elif COND:
  ...]
[else:
  ...]

This IF-clause like must be immediately after FOR- or WHILE-cycle (only comment allowed between). It looks like a regular IF, but COND is special.
COND may be "break", "pass" or "finally". "if break:" - if used break-operator to exit cycle. "if pass:" - cycle executed 0 times. "if finally:" - cycle executed 0 or more times ("pass-case"  is included in "finally-case"). For compatibility only "else:" means "if finally:".
It's compatible enhancement. No new keyword. There can be no combination "break", "pass" or "finally" after "if"/"elif:" in current version.

----------
components: Interpreter Core
messages: 373479
nosy: catrudis
priority: normal
severity: normal
status: open
title: New clause in FOR and WHILE instead of ELSE
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41272>
_______________________________________

From report at bugs.python.org  Fri Jul 10 16:56:39 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Fri, 10 Jul 2020 20:56:39 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594414599.34.0.231954175699.issue41261@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

Yes, indeed, please, because I don't know what I would do for 3.9 if this is not fixed. :D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 16:59:10 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Fri, 10 Jul 2020 20:59:10 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594414750.6.0.142347854646.issue41261@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

> If sys.modules['_ast'] is cleared and then _ast is imported again, _PyState_AddModule() is called to store the new _ast module instance which calls astmodule_clear() on the old module instance.

I'm confused about this. In the repro below the sys.modules.clear() is indeed cleared, but references to all modules are retained. 

Where is the garbage collection/module re-initialization coming from? All of the references are live.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:06:28 2020
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Fri, 10 Jul 2020 21:06:28 +0000
Subject: [issue41261] 3.9-dev SEGV in object_recursive_isinstance in
 ast.literal_eval
In-Reply-To: <1594319150.59.0.418042347071.issue41261@roundup.psfhosted.org>
Message-ID: <1594415188.73.0.11560114564.issue41261@roundup.psfhosted.org>


Arcadiy Ivanov <arcadiy at ivanov.biz> added the comment:

Nevermind, `ast`/`_ast` is not pre-loaded by default, so it's in fact getting GC'ed after the first `run_path` is executed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41261>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:08:56 2020
From: report at bugs.python.org (Tony)
Date: Fri, 10 Jul 2020 21:08:56 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
Message-ID: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>


New submission from Tony <tony.solomonik at gmail.com>:

Using recv_into instead of recv in the transport _loop_reading will speed up the process.

>From what I checked it's about 120% performance increase.

This is only because there should not be a new buffer allocated each time we call recv, it's really wasteful.

----------
messages: 373483
nosy: tontinton
priority: normal
severity: normal
status: open
title: asyncio: proactor read transport: use recv_into instead of recv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:13:26 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Jul 2020 21:13:26 +0000
Subject: [issue41253] unittest -h shows a flag -s but it doesn't work
In-Reply-To: <1594269450.68.0.624090697882.issue41253@roundup.psfhosted.org>
Message-ID: <1594415606.69.0.960514285311.issue41253@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This appears to just be a misunderstanding: -s is a flag to "unittest discover", not to "unittest" itself. I think this is clear from the help text, so I'm closing this.

If I'm incorrect, let me know.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41253>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:14:55 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Jul 2020 21:14:55 +0000
Subject: [issue41256] activate script created by venv is not smart enough
In-Reply-To: <1594288628.21.0.90149093497.issue41256@roundup.psfhosted.org>
Message-ID: <1594415695.03.0.641175024064.issue41256@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Changing versions to those that are currently receiving support.

----------
nosy: +eric.smith
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41256>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:21:27 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Jul 2020 21:21:27 +0000
Subject: [issue41272] New clause in FOR and WHILE instead of ELSE
In-Reply-To: <1594413840.56.0.248219439277.issue41272@roundup.psfhosted.org>
Message-ID: <1594416087.55.0.0993654369895.issue41272@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You should bring this up on the python-ideas mailing list so that it gets more visibility.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41272>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:33:36 2020
From: report at bugs.python.org (Tony)
Date: Fri, 10 Jul 2020 21:33:36 +0000
Subject: [issue41270] NamedTemporaryFile is not its own iterator.
In-Reply-To: <1594389522.96.0.51886326593.issue41270@roundup.psfhosted.org>
Message-ID: <1594416816.2.0.51499904004.issue41270@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
nosy: +tontinton
nosy_count: 3.0 -> 4.0
pull_requests: +20585
pull_request: https://github.com/python/cpython/pull/21439

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41270>
_______________________________________

From report at bugs.python.org  Fri Jul 10 17:44:43 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Fri, 10 Jul 2020 21:44:43 +0000
Subject: [issue41274] Better way to random.seed()?
Message-ID: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>


New submission from Juan Jimenez <flybd5 at gmail.com>:

I have invented a new way to seed the random number generator with about as random a source of seeds as can be found: hashes generated from high cadence, high resolution images of the surface of the Sun. These are captured by the Solar Dynamics Observatory's (SDO) Atmospheric Imaging Assembly's (AIA) cameras at various frequencies. I wrote the POC code in Python and can be seen at https://github.com/flybd5/heliorandom. The HelioViewer project liked the idea and modified their API to do essentially what my POC code does at https://api.helioviewer.org/?action=getRandomSeed. Perhaps a solarseed() call could be created for the library to get seeds that way rather than from the system clock?

----------
components: Library (Lib)
messages: 373487
nosy: flybd5
priority: normal
severity: normal
status: open
title: Better way to random.seed()?
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 18:37:03 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 10 Jul 2020 22:37:03 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594420623.05.0.604327197524.issue41274@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi, this is very specific and I don't think a way to seed the random generator using a third uncontrolled party will get merged in Python. You should probably try to package this as a third party library.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 19:42:14 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Fri, 10 Jul 2020 23:42:14 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594424534.65.0.168932514839.issue41274@roundup.psfhosted.org>


Juan Jimenez <flybd5 at gmail.com> added the comment:

I'm not a Python guru, but I was wondering, is it possible to write a new module that overrides the seed() method in the random library in its initialization code and replaces it with this method of seeding the generator?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 20:12:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Jul 2020 00:12:59 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594426379.33.0.344189275698.issue41274@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> is it possible to write a new module that overrides the seed()
> method in the random library in its initialization code and 
> replaces it with this method of seeding the generator?

Yes.  The simplest way is override seed() in a subclass.  You can put that subclass in a new module if you like and can even call the class "Random" if desired.

>>> class InputRandom(random.Random):
	def seed(self, a=None):
		if a is None:
			a = int(input('Enter a seed: '))
		super().seed(a)

		
>>> r = InputRandom()
Enter a seed: 1234
>>> r.random()
0.9664535356921388
>>> r.random()
0.4407325991753527
>>> r.seed()
Enter a seed: 1234
>>> r.random()
0.9664535356921388
>>> r.seed(1234)
>>> r.random()
0.9664535356921388

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 20:14:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Jul 2020 00:14:23 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594426463.1.0.156858715303.issue41274@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking as closed for these reasons listed by R?mi Lapeyre.

Also note that the default is to use a system source of entropy.  Time is only used as a fallback if such as source is unavailable.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 20:16:15 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Sat, 11 Jul 2020 00:16:15 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594426575.01.0.978707845379.issue41274@roundup.psfhosted.org>


Juan Jimenez <flybd5 at gmail.com> added the comment:

Thanks R?mi. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 20:21:13 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Jul 2020 00:21:13 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1594426873.9.0.669036966061.issue41259@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think it's fine as-is.  The real purpose of the example is show basic patterns in writing regexes.  Pig-latin examples or searching for words ending in -ly make for nice beginner examples.   I like the OP's modification because it teaches a general skill (the importance of \b for making sure you get whole words).

We could add a link to the Natural Language Toolkit for people who are getting serious about searching for parts of speech.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Fri Jul 10 20:23:52 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jul 2020 00:23:52 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594427032.59.0.165554967664.issue41274@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is definitely cool though. It might make a really sweet example in the demos that come with Python, or in the tutorial, showcasing both the awesomeness of HelioViewer and how to use Python to connect to web APIs.

https://github.com/python/cpython/tree/master/Tools/demo

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:21:40 2020
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 11 Jul 2020 01:21:40 +0000
Subject: [issue41004] [CVE-2020-14422] Hash collisions in IPv4Interface and
 IPv6Interface
In-Reply-To: <1592399512.32.0.283218763722.issue41004@roundup.psfhosted.org>
Message-ID: <1594430500.93.0.395648787946.issue41004@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41004>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:44:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 01:44:57 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1594431897.94.0.337684997344.issue41212@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python internally uses an encoding system that represents all unicode chars efficiently, including O(1) indexing.  It is not utf-8, which does not do O(1) indexing.

There is already an issue about upgrading (separately) the Python Windows and macOS installers to install tcl/tk 8.6.9.

With the currrent 8.6.9 and probably earlier, and since an important tkinter patch last fall for #13153, a tkinter/tk text widget will display astral characters that the font in use can produce.  For example, in 3.9.0, I see the TV set printed in IDLE
>>> '\U0001f4bb'
'?'
but not in the Windows Console Python REPL, which shows 'box space box box'.

However, astral characters discombobutate editing (#39126),at least on Windows, they are counted as 2 or 4 chars.  The difference between behavior before and after Serhiy's patch and between display and editing likely explains different reports on SO.

----------
nosy: +terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41212>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:55:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 01:55:00 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
In-Reply-To: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>
Message-ID: <1594432500.6.0.621240712587.issue41228@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 344dce312a0cf86d5a5772d54843cc179acaf6e3 by Nima Dini in branch 'master':
bpo-41228: Fix /a/are/ in monthcalendar() descripton (GH-21372)
https://github.com/python/cpython/commit/344dce312a0cf86d5a5772d54843cc179acaf6e3


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:55:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 01:55:31 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1594432531.08.0.33275448827.issue41229@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:55:26 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Jul 2020 01:55:26 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
In-Reply-To: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>
Message-ID: <1594432526.78.0.55404280488.issue41228@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20586
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21440

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:55:33 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Jul 2020 01:55:33 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
In-Reply-To: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>
Message-ID: <1594432533.37.0.652571303944.issue41228@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20587
pull_request: https://github.com/python/cpython/pull/21441

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:56:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 01:56:16 +0000
Subject: [issue41231] Type annotations lost when using wraps by default
In-Reply-To: <1594142955.77.0.852569543435.issue41231@roundup.psfhosted.org>
Message-ID: <1594432576.69.0.477531347217.issue41231@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Only 3.8+ for bug fixes.

----------
nosy: +terry.reedy
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41231>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:56:29 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 01:56:29 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1594432589.21.0.0852039384586.issue41229@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Only 3.8+ for bug fixes.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Fri Jul 10 21:58:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 01:58:22 +0000
Subject: [issue41232] Python `functools.wraps` doesn't deal with defaults
 correctly
In-Reply-To: <1594159222.49.0.432639092165.issue41232@roundup.psfhosted.org>
Message-ID: <1594432702.71.0.688067369701.issue41232@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this actually a bugfix?

----------
nosy: +terry.reedy
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41232>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:07:40 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Jul 2020 02:07:40 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
In-Reply-To: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>
Message-ID: <1594433260.74.0.878343690535.issue41228@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a77b1f6b5bb3b76cb913e62ad68f5fd803d515bd by Miss Islington (bot) in branch '3.9':
bpo-41228: Fix /a/are/ in monthcalendar() descripton (GH-21372)
https://github.com/python/cpython/commit/a77b1f6b5bb3b76cb913e62ad68f5fd803d515bd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:07:38 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 02:07:38 +0000
Subject: [issue41233] Missing links to errnos on Built-in Exceptions page
In-Reply-To: <1594161566.11.0.329793156149.issue41233@roundup.psfhosted.org>
Message-ID: <1594433258.49.0.825567358249.issue41233@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Only 3.8+ for bug fixes.

----------
nosy: +terry.reedy
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41233>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:09:10 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Jul 2020 02:09:10 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
In-Reply-To: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>
Message-ID: <1594433350.56.0.169382759863.issue41228@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c77f71f9819022fa3adeb2f710e564a392ff24c6 by Miss Islington (bot) in branch '3.8':
bpo-41228: Fix /a/are/ in monthcalendar() descripton (GH-21372)
https://github.com/python/cpython/commit/c77f71f9819022fa3adeb2f710e564a392ff24c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:11:25 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 02:11:25 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1594433485.61.0.61830624792.issue41273@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
keywords: +patch
pull_requests: +20588
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21439

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:14:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 02:14:16 +0000
Subject: [issue41234] Remove symbol.sym_name
In-Reply-To: <1594162290.58.0.321462635772.issue41234@roundup.psfhosted.org>
Message-ID: <1594433656.76.0.725103416343.issue41234@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified that import symbol works in 3.9 and raises in 3.10.  So yes, doc and its reference should have gone too.  Good catch.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41234>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:41:58 2020
From: report at bugs.python.org (JustAnotherArchivist)
Date: Sat, 11 Jul 2020 02:41:58 +0000
Subject: [issue41275] Clarify whether Futures can be awaited multiple times
Message-ID: <1594435318.81.0.780838422603.issue41275@roundup.psfhosted.org>


New submission from JustAnotherArchivist <justanotherarchivist at riseup.net>:

While the situation is clear regarding coroutine objects (#25887), as far as I can see, the documentation doesn't specify whether asyncio.Futures can be awaited multiple times. The code has always (at least since the integration into CPython) allowed for it since Future.__await__ simply returns Future.result() if it is already done. Is this guaranteed/intended behaviour, as also implied by some of the comments on #25887, or is it considered an implementation detail?

Here are the only two things I found in the documentation regarding this:

> library/asyncio-task: When a Future object is awaited it means that the coroutine will wait until the Future is resolved in some other place.

> library/asyncio-future: Future is an awaitable object. Coroutines can await on Future objects until they either have a result or an exception set, or until they are cancelled.

Neither of these say anything about awaiting a Future that is already resolved, i.e. has a result, has an exception, or was cancelled.

If this is intended to be guaranteed, it should be mentioned in the Future documentation. If it is considered an implementation detail, it's probably not necessary to explicitly mention this anywhere, but it might be a good idea to add another line to e.g. the asyncio.wait example on how to correctly retrieve the result of an already-awaited Future/Task.

----------
components: asyncio
messages: 373504
nosy: JustAnotherArchivist, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Clarify whether Futures can be awaited multiple times
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41275>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:48:06 2020
From: report at bugs.python.org (Felipe Rodrigues)
Date: Sat, 11 Jul 2020 02:48:06 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594435686.09.0.578983717308.issue41220@roundup.psfhosted.org>


Felipe Rodrigues <felipe at felipevr.com> added the comment:

Hello all,

I love discussions about caching! While I do see the point of Itayazolay's proposal, I think that it should be on the _caller_ to solve the caching issue, and not on the _callee_ to provide a way to make it happen.

That is, I think that if one wants to use a cache, they should make sure their arguments are hashable and not that we should modify called functions to provide workarounds for those.

----------
nosy: +fbidu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:50:09 2020
From: report at bugs.python.org (Felipe Rodrigues)
Date: Sat, 11 Jul 2020 02:50:09 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594435809.58.0.0372549161248.issue41220@roundup.psfhosted.org>


Felipe Rodrigues <felipe at felipevr.com> added the comment:

Correction: (...) on the _caller_ to solve the hashing* issue (...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:01:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 03:01:16 +0000
Subject: [issue41236] "about" button in MacOS caused an error
In-Reply-To: <1594188316.81.0.4505690312.issue41236@roundup.psfhosted.org>
Message-ID: <1594436476.77.0.344461336878.issue41236@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Messages like this are an occasional nuisance when shutting down a tkinter app started in a terminal/console window.  I have gone to a lot of effort to suppress than in IDLE GUI tests so that other developers do not suffer the noise or puzzlement of thinking that there maybe was a test failure.

I can get them now *occasionally* if I start IDLE from a Windows console, open multiple windows, and close by right clicking the toolbar icon and selecting "Close all Windows" instead of closing properly by closing each window or selecting File => Exit.  I consider trying to fix this shutdown buglet to be low priority.  

When starting IDLE from an IDLE icon, any such messages go to /dev/NULL. 

After experimenting, I believe Baozhen started IDLE from Terminal with 'python3 -m idlelib'.  The top menu then has second entry "Python" instead of "IDLE" with first item "About Python" instead of "About IDLE".  But it brings up the "About IDLE" tk dialog box.  I also suspect  there was some shutdown action, so we must know every user action needed to reproduce the issue, and then see if it occurs in 3.8 or later. 

Ned, when I run 3.9 test.pythoninfo, I am asked to install gcc tools and maybe xcode.  Is this expected?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41236>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:04:09 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 03:04:09 +0000
Subject: [issue41228] Fix the typo in the description of
 calendar.monthcalendar(year, month)
In-Reply-To: <1594138367.74.0.319169910196.issue41228@roundup.psfhosted.org>
Message-ID: <1594436649.58.0.736489429733.issue41228@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41228>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:09:00 2020
From: report at bugs.python.org (Ma Lin)
Date: Sat, 11 Jul 2020 03:09:00 +0000
Subject: [issue41265] lzma/bz2 module: inefficient buffer growth algorithm
In-Reply-To: <1594370733.96.0.701626485898.issue41265@roundup.psfhosted.org>
Message-ID: <1594436940.78.0.510490716595.issue41265@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Maybe the zlib module can also use the same algorithm.

zlib module's initial buffer size is 16KB [1], each time the size doubles [2].

[1] zlib module's initial buffer size:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/zlibmodule.c#L32

[2] zlib module buffer growth algorithm:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/zlibmodule.c#L174

----------
nosy: +inada.naoki, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41265>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:08:49 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 11 Jul 2020 03:08:49 +0000
Subject: [issue41202] Allow to provide custom exception handler to
 asyncio.run()
In-Reply-To: <1593786366.9.0.0322970631337.issue41202@roundup.psfhosted.org>
Message-ID: <1594436929.28.0.923836171774.issue41202@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Should I set status for this issue for closed with resolution rejected ?

I'll proceed with closing the issue.

> Should I delete branch on my forked git repo ?
> Can I delete my forked git repo ?

Might as well delete the branch, but the forked repo might be useful to keep around should you choose to open a PR to CPython in the future (although you can also just create a new one later). If you are interested in working on something else in the future, I'd recommend looking at the "newcomer friendly"/"easy" issues, or just looking for an existing open issue that you're interested in helping with. In most cases, working with a clearly defined issue is much easier than trying to propose a new one and getting it merged.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41202>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:14:16 2020
From: report at bugs.python.org (JustAnotherArchivist)
Date: Sat, 11 Jul 2020 03:14:16 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1594437256.5.0.185446587393.issue32528@roundup.psfhosted.org>


JustAnotherArchivist <justanotherarchivist at riseup.net> added the comment:

As another datapoint, this also broke some of my code on 3.8 because I was using `concurrent.futures.CancelledError` rather than `asyncio.CancelledError` to handle cancelled futures. And I'm certainly not the only one to have done this given that it's mentioned in at least two Stack Overflow answers: https://stackoverflow.com/a/38655063 and https://stackoverflow.com/a/36277556

While I understand the rationale behind this change, it would've been good to include this inheritance detail in the 3.8 release notes.

----------
nosy: +JustAnotherArchivist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:48:08 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Jul 2020 03:48:08 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1594437256.5.0.185446587393.issue32528@roundup.psfhosted.org>
Message-ID: <CAP7+vJJiw6iPOAM6Jno858q+oUr6PJxsx00=jbO0TgXO=jnQ0A@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Can you send a PR against what?s new 3.8?

On Fri, Jul 10, 2020 at 20:14 JustAnotherArchivist <report at bugs.python.org>
wrote:

>
> JustAnotherArchivist <justanotherarchivist at riseup.net> added the comment:
>
> As another datapoint, this also broke some of my code on 3.8 because I was
> using `concurrent.futures.CancelledError` rather than
> `asyncio.CancelledError` to handle cancelled futures. And I'm certainly not
> the only one to have done this given that it's mentioned in at least two
> Stack Overflow answers: https://stackoverflow.com/a/38655063 and
> https://stackoverflow.com/a/36277556
>
> While I understand the rationale behind this change, it would've been good
> to include this inheritance detail in the 3.8 release notes.
>
> ----------
> nosy: +JustAnotherArchivist
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32528>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Sat Jul 11 00:02:02 2020
From: report at bugs.python.org (Calvin Davis)
Date: Sat, 11 Jul 2020 04:02:02 +0000
Subject: [issue41276] Min / Max returns different values depending on
 parameter order
Message-ID: <1594440122.62.0.379783406728.issue41276@roundup.psfhosted.org>


New submission from Calvin Davis <mynameiscalvindavis at gmail.com>:

See attached image

The behavior of min() (and probably max and other related functions) changes depending on the order of the parameters it sorts.

In the image, I sorted two tuples, coordinate points, with the same Y value and different X values. When the X values were in increasing order, finding the minimum x value and minimum y value were the same. However if the list was reversed, finding the minimum x and y values in the list provided different results.

----------
assignee: terry.reedy
components: IDLE
files: yqzRk0Y.png
messages: 373512
nosy: Calvin Davis, terry.reedy
priority: normal
severity: normal
status: open
title: Min / Max returns different values depending on parameter order
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49314/yqzRk0Y.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41276>
_______________________________________

From report at bugs.python.org  Sat Jul 11 00:16:23 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jul 2020 04:16:23 +0000
Subject: [issue41276] Min / Max returns different values depending on
 parameter order
In-Reply-To: <1594440122.62.0.379783406728.issue41276@roundup.psfhosted.org>
Message-ID: <1594440983.03.0.188107814152.issue41276@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is correct behaviour. What makes you think otherwise?

For future bug reports, please don't post screen shots of text, copy and paste the text into the body of your bug report.

Posting screenshots makes it difficult for us to copy and run your code, and discriminates against the blind and visually impaired who may be reading this with a screen-reader, which doesn't not work with images.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41276>
_______________________________________

From report at bugs.python.org  Sat Jul 11 00:32:06 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jul 2020 04:32:06 +0000
Subject: [issue41276] Min / Max returns different values depending on
 parameter order
In-Reply-To: <1594440122.62.0.379783406728.issue41276@roundup.psfhosted.org>
Message-ID: <1594441926.52.0.833852741382.issue41276@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

In your first example, `min([(-5, 2), (0, 2)])` the min() function compares the two tuples and finds that the first one is lexicographically smaller:

    py> (-5, 2) < (0, 2)
    True

so (-5, 2) is considered the minimum. In the second example, using the key function compares 2 with 2, but since they are equal, the *first* tuple wins and is considered the minimum, and so using the key function doesn't change the result.

In your third example, after reversing the list, you have `min([(0, 2), (-5, 2)])` and the min() function compares the two tuples and finds the *second* tuple is the smaller:

    py> (0, 2) < (-5, 2)
    False

But in the fourth example, using the key function, yet again the comparison compares 2 with 2 and finds them equal, and so the *first* tuple wins and (0, 2) is declared the minimum.

When using the key function, only the second item of the tuple is looked at; the first item is ignored. So the difference between 0 and -5 is irrelevant, and the tie is decided by which element was seen first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41276>
_______________________________________

From report at bugs.python.org  Sat Jul 11 01:02:51 2020
From: report at bugs.python.org (Calvin Davis)
Date: Sat, 11 Jul 2020 05:02:51 +0000
Subject: [issue41276] Min / Max returns different values depending on
 parameter order
In-Reply-To: <1594440122.62.0.379783406728.issue41276@roundup.psfhosted.org>
Message-ID: <1594443771.5.0.0550925697938.issue41276@roundup.psfhosted.org>


Calvin Davis <mynameiscalvindavis at gmail.com> added the comment:

Thank you for the clarification, sorry for the report! You're awesome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41276>
_______________________________________

From report at bugs.python.org  Sat Jul 11 01:45:59 2020
From: report at bugs.python.org (Pablo Dumas)
Date: Sat, 11 Jul 2020 05:45:59 +0000
Subject: [issue41277] documentation: os.setxattr() errno EEXIST and ENODATA
Message-ID: <1594446359.56.0.57719330174.issue41277@roundup.psfhosted.org>


New submission from Pablo Dumas <pablodumas94 at gmail.com>:

Shouldn't os.setxattr() errno EEXIST be when "XATTR_CREATE was specified, and the attribute exists already" and errno ENODATA be when "XATTR_REPLACE was specified, and the attribute does not exist."? In the current os module documentation, it's the other way around: "If XATTR_REPLACE is given and the attribute does not exist, EEXISTS will be raised. If XATTR_CREATE is given and the attribute already exists, the attribute will not be created and ENODATA will be raised."... Thanks!

----------
messages: 373516
nosy: w0rthle$$
priority: normal
severity: normal
status: open
title: documentation: os.setxattr() errno EEXIST and ENODATA
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41277>
_______________________________________

From report at bugs.python.org  Sat Jul 11 02:32:36 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Jul 2020 06:32:36 +0000
Subject: [issue41236] "about" button in MacOS caused an error
In-Reply-To: <1594188316.81.0.4505690312.issue41236@roundup.psfhosted.org>
Message-ID: <1594449156.35.0.52189488532.issue41236@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Terry, based on the error message provided, i.e. "About Widget Demo", I assumed that the poster was not using IDLE here. But we can't tell without more input.

"when I run 3.9 test.pythoninfo, I am asked to install gcc tools and maybe xcode.  Is this expected?"

When doing Python development on macOS, you will need to have the Apple-supplied development tools installed and ones appropriate for the macOS release. As the Developer's Guide explains (https://devguide.python.org/setup/#macos-and-os-x), the necessary tools are available if you install the full Xcode development environment from the Mac App Store but that's a big download and most of it is not necessary for just cpython work. If you haven't already downloaded Xcode, then the first time you (or, in this case test.pythoninfo) try to use one of the development tools from the terminal shell command line, macOS offers to download and install a lightweight subset of what's available in Xcode, called the Command Line Tools.  You can also force the installation of the CLT by using "xcode-select --install". Once the CLT are installed, they are normally automatically updated as needed by the macOS Software Update process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41236>
_______________________________________

From report at bugs.python.org  Sat Jul 11 03:12:44 2020
From: report at bugs.python.org (Alex)
Date: Sat, 11 Jul 2020 07:12:44 +0000
Subject: [issue41278] Wrong Completion on Editing Mode of IDLE
Message-ID: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>


New submission from Alex <2423067593 at qq.com>:

When I type (on editing mode, not interacting mode) __main__. + Ctrl+Space, the completion window shows 'idlelib'.

----------
assignee: terry.reedy
components: IDLE
messages: 373518
nosy: Alex-Python-Programmer, terry.reedy
priority: normal
severity: normal
status: open
title: Wrong Completion on Editing Mode of IDLE
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Sat Jul 11 03:19:49 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Sat, 11 Jul 2020 07:19:49 +0000
Subject: [issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output
 when input is paticular LZMA+BCJ data
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594451989.18.0.674730192117.issue41210@roundup.psfhosted.org>


Hiroshi Miura <miurahr at linux.com> added the comment:

Here is a BCJ only CFFI test project.
https://github.com/miurahr/bcj-cffi

It imports two bcj_x86 C sources, one is from liblzma (src/xz_bcj_x86.c) taht is bind with python's lzma module, and the other is from xz-embbed project for linux kernel.(src/xz_simple_bcj.c)

We can observe that

1. it has an interface which overwrite buffer
2. it returns good resulted buffer (digest assertion) in both case
3. it returns 4 bytes less size than expected.

for 3, it is because return value  of BCJ is defined such as

```
	size -= 4;
	for (i = 0; i < size; ++i) {...}
        return i;
```
and  variable i sometimes increment 4 bytes when target sequence is found and processed.

It may be natural that a size value returned from BCJ filter is often 4 bytes smaller than actual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Sat Jul 11 05:05:26 2020
From: report at bugs.python.org (Hugo van Kemenade)
Date: Sat, 11 Jul 2020 09:05:26 +0000
Subject: [issue41268] 3.9-dev regression? TypeError: exec_module() missing 1
 required positional argument: 'module'
In-Reply-To: <1594385264.3.0.0834998947861.issue41268@roundup.psfhosted.org>
Message-ID: <1594458326.08.0.51531706172.issue41268@roundup.psfhosted.org>


Hugo van Kemenade <hugovk+python at gmail.com> added the comment:

Okay, looks like this is actually a setuptools issue, introduced in version 47.3.2.

Reported: https://github.com/pypa/setuptools/issues/2246

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41268>
_______________________________________

From report at bugs.python.org  Sat Jul 11 05:09:17 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 09:09:17 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1594458557.16.0.0370657789984.issue41273@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
pull_requests: +20589
pull_request: https://github.com/python/cpython/pull/21442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Sat Jul 11 05:09:17 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 09:09:17 +0000
Subject: [issue41270] NamedTemporaryFile is not its own iterator.
In-Reply-To: <1594389522.96.0.51886326593.issue41270@roundup.psfhosted.org>
Message-ID: <1594458557.25.0.761197214182.issue41270@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
pull_requests: +20590
pull_request: https://github.com/python/cpython/pull/21442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41270>
_______________________________________

From report at bugs.python.org  Sat Jul 11 06:18:45 2020
From: report at bugs.python.org (Itay azolay)
Date: Sat, 11 Jul 2020 10:18:45 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594462725.02.0.333797455478.issue41220@roundup.psfhosted.org>


Itay azolay <itayazolay at gmail.com> added the comment:

Hey Felipe! Thanks for stepping in!
I do get your argument. 
However, in my opinion, I try to argue the same thing for max or sorted.
"if one wants to use `sorted`, they should make sure their arguments are comparable".
However, it is not the case, since we do have the `key` argument for sorted or max. 
Also, I don't believe caching equals hashing. 
Maybe from the technical point view, it does, but in reality, One can(and probably will) cache unhashable object, whether we give the option to do so or not.
I think, embedding the key argument in lru_cache, we allow the caller(developer) to solve the caching issue, in a way that is right according to his implementation of the cached function and its arguments.

Unrelated, this is my first feature proposal for python. I want to thank you for taking the time to think and answer with some very good arguments and respect, I truly enjoy this little debate we have here :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Sat Jul 11 08:13:17 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 11 Jul 2020 12:13:17 +0000
Subject: [issue41136] argparse uses default encoding when read arguments from
 file
In-Reply-To: <1593242027.84.0.221105259078.issue41136@roundup.psfhosted.org>
Message-ID: <1594469597.69.0.9321133338.issue41136@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +20592
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21444

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41136>
_______________________________________

From report at bugs.python.org  Sat Jul 11 09:33:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 13:33:41 +0000
Subject: [issue41236] "about" button in MacOS caused an error
In-Reply-To: <1594188316.81.0.4505690312.issue41236@roundup.psfhosted.org>
Message-ID: <1594474421.47.0.118763539056.issue41236@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You're right.  "python3.9 -m tkinter" runs the tkinter widget demo.  And python >= About python brings up 'about tkinter' window.  I just deleted 3.7 so I cannot easily test.  3.8 works also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41236>
_______________________________________

From report at bugs.python.org  Sat Jul 11 09:37:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 13:37:02 +0000
Subject: [issue41278] Wrong Completion on Editing Mode of IDLE
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594474622.83.0.620383798503.issue41278@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Windows, with 3.8.4rc1 and 3.8 repository, ^space brings up proper list.  Give more details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Sat Jul 11 10:07:13 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Sat, 11 Jul 2020 14:07:13 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594476433.53.0.621275594996.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

Nevertheless, I have an exploitable crash for the Pickle module too right now, but  as you're not interested, I didn't open an issue to share it. Thanks anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:23:40 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 16:23:40 +0000
Subject: [issue41279] Convert StreamReaderProtocol to a BufferedProtocol
Message-ID: <1594484620.37.0.437755734421.issue41279@roundup.psfhosted.org>


New submission from Tony <tony.solomonik at gmail.com>:

This will greatly increase performance, from my internal tests it was about 150% on linux.

Using read_into instead of read will make it so we do not allocate a new buffer each time data is received.

----------
messages: 373526
nosy: tontinton
priority: normal
severity: normal
status: open
title: Convert StreamReaderProtocol to a BufferedProtocol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41279>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:27:11 2020
From: report at bugs.python.org (Anselm Kiefner)
Date: Sat, 11 Jul 2020 16:27:11 +0000
Subject: [issue38556] Walrus operator in list comprehensions [Python 3.8.0]
In-Reply-To: <1571747965.17.0.120540707485.issue38556@roundup.psfhosted.org>
Message-ID: <1594484831.56.0.149501643596.issue38556@roundup.psfhosted.org>


Anselm Kiefner <amogorkon at gmail.com> added the comment:

I just stumbled over this same restriction and when I googled for "SyntaxError: cannot assign to named expression", 0 actual results showed - an absolute unicorn for a Python error.

> "Due to design constraints in the reference implementation (the symbol table analyser cannot easily detect when names are re-used between the leftmost comprehension iterable expression and the rest of the comprehension), named expressions are disallowed entirely as part of comprehension iterable expressions (the part after each "in", and before any subsequent "if" or "for" keyword):"

Might the new PEG parser maybe help alleviate this restriction, so we could declare this a bug instead?

----------
nosy: +Anselm Kiefner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38556>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:34:15 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jul 2020 16:34:15 +0000
Subject: [issue41279] Convert StreamReaderProtocol to a BufferedProtocol
In-Reply-To: <1594484620.37.0.437755734421.issue41279@roundup.psfhosted.org>
Message-ID: <1594485255.14.0.478843530257.issue41279@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +asyncio
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41279>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:11:59 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 11 Jul 2020 17:11:59 +0000
Subject: [issue41266] Wrong hint when class methods and builtins named same
In-Reply-To: <1594370995.93.0.883531134582.issue41266@roundup.psfhosted.org>
Message-ID: <1594487519.01.0.477932960805.issue41266@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Both of the following cases give the correct popup help information:

float.hex(

And:

t = type("test_hex", (), {"hex": lambda nothing: None})
t.hex(

The reason your case fails is because IDLE doesn't evaluate `1.3` to a float and does indeed use the normal `hex` method help (as you established with your `list` test).

----------
nosy: +epaine

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41266>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:18:17 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 17:18:17 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1594487897.77.0.0184269808486.issue41273@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
pull_requests: +20593
pull_request: https://github.com/python/cpython/pull/21446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:23:08 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 17:23:08 +0000
Subject: [issue41279] Convert StreamReaderProtocol to a BufferedProtocol
In-Reply-To: <1594484620.37.0.437755734421.issue41279@roundup.psfhosted.org>
Message-ID: <1594488188.0.0.311417479774.issue41279@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
keywords: +patch
pull_requests: +20594
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41279>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:26:07 2020
From: report at bugs.python.org (=?utf-8?q?Tymek_Wo=C5=82od=C5=BAko?=)
Date: Sat, 11 Jul 2020 17:26:07 +0000
Subject: [issue38490] statistics: add covariance, Pearson's correlation,
 and simple linear regression
In-Reply-To: <1590180326.53.0.258219994102.issue38490@roundup.psfhosted.org>
Message-ID: <CAHa5zCvChFm21vYasgoqWo_Noo3zmDU016JkH0WZFXzXWKJ1-A@mail.gmail.com>


Tymek Wo?od?ko <twolodzko at gmail.com> added the comment:

Is there anything more I should do about the PR?

Sincerely,
Tim

On Fri, May 22, 2020 at 10:45 PM Cheryl Sabella <report at bugs.python.org>
wrote:

>
> Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:
>
> @steven.daprano and @tim.peters, please take a look at the PR as it is
> just waiting on your approval.  Thanks!
>
> ----------
> nosy: +cheryl.sabella
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38490>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38490>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:52:29 2020
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 11 Jul 2020 17:52:29 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1594489948.99.0.315886283485.issue39542@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Raymond, did you replace the screenshot with a later one showing that things are fixed now?  The timestamp suggests it went up at the same time as your comment, but what I see in the .png file is that the two are identical other than addresses.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Sat Jul 11 14:15:59 2020
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 11 Jul 2020 18:15:59 +0000
Subject: [issue41212] Emoji Unicode failing in standard release of Python
 3.8.3 / tkinter 8.6.8
In-Reply-To: <1593938513.79.0.0840613068197.issue41212@roundup.psfhosted.org>
Message-ID: <1594491359.69.0.540298614145.issue41212@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

@Ben Griffin -- Unicode has defined astral characters for a while, but they were explicitly intended for rare characters, with any living languages intended for the basic plane.  It is only the most recent releases of unicode that have broken the "most people won't need this" expectation, so it wasn't unreasonable for languages targeting memory-constrained devices to make astral support at best a compile-time operation.  

I've seen a draft for an upcoming spec update of an old but still-supported language (extended Gerber, for photoplotting machines) that "handles" this simply by clarifying that their unicode support is limited to characters < 65K.  Given that their use of unicode is essentially limited to comments, and there is plenty of hardware that can't be updated ... this is may well be correct.

Python itself does the right thing, and tcl can't do the right thing anyhow without font support ... so this may be fixed in less time than it would take to replace Tk/Tcl.  If you need a faster workaround, consider a private-use-area and private font.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41212>
_______________________________________

From report at bugs.python.org  Sat Jul 11 14:36:42 2020
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 11 Jul 2020 18:36:42 +0000
Subject: [issue41217] Obsolete note for default asyncio event loop on Windows
In-Reply-To: <1594023051.16.0.859268804549.issue41217@roundup.psfhosted.org>
Message-ID: <1594492602.23.0.0686894336392.issue41217@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Looks good to me.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41217>
_______________________________________

From report at bugs.python.org  Sat Jul 11 14:41:55 2020
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 11 Jul 2020 18:41:55 +0000
Subject: [issue41246] IOCP Proactor same socket overlapped callbacks
In-Reply-To: <1594228808.35.0.788748619653.issue41246@roundup.psfhosted.org>
Message-ID: <1594492915.2.0.833190070642.issue41246@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Looks good to me.  

I at first worried that the different function names were useful metadata that was getting lost -- but the names were already duplicated in several cases.  *If* that is still a concern for the committer, then instead of repeating the code (as current production does), each section should just say newname=origname before registering the static method (as the patch does), and should bind a distinct name for each usage.

----------
nosy: +Jim.Jewett
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41246>
_______________________________________

From report at bugs.python.org  Sat Jul 11 14:47:15 2020
From: report at bugs.python.org (Tony)
Date: Sat, 11 Jul 2020 18:47:15 +0000
Subject: [issue41246] IOCP Proactor same socket overlapped callbacks
In-Reply-To: <1594228808.35.0.788748619653.issue41246@roundup.psfhosted.org>
Message-ID: <1594493235.25.0.99057478336.issue41246@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

I feel like the metadata is not really a concern here. I like when there is no code duplication :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41246>
_______________________________________

From report at bugs.python.org  Sat Jul 11 14:54:42 2020
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 11 Jul 2020 18:54:42 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1594493682.78.0.974938088773.issue41220@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Going back to Raymond's analysis, this is useful when at least some of the parameters either do not change the result, or are not hashable.

At a minimum, you need to figure out which parameters those are, and whether to drop them or transform them.

Is this already sufficiently rare or tricky that a subclass is justified, instead of trying to shoehorn things into a single key method?

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Sat Jul 11 15:56:10 2020
From: report at bugs.python.org (=?utf-8?b?VGhvbWFzIEdsw6TDn2xl?=)
Date: Sat, 11 Jul 2020 19:56:10 +0000
Subject: [issue34624] -W option and PYTHONWARNINGS env variable does not
 accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1594497370.5.0.101744843492.issue34624@roundup.psfhosted.org>


Thomas Gl??le <thomas at coldfix.de> added the comment:

Hi, I have rebased this on master and fixed the minor conflict. Let me know if there is anything else I can do.

Best, Thomas

----------
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Sat Jul 11 16:29:20 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Jul 2020 20:29:20 +0000
Subject: [issue41268] 3.9-dev regression? TypeError: exec_module() missing 1
 required positional argument: 'module'
In-Reply-To: <1594385264.3.0.0834998947861.issue41268@roundup.psfhosted.org>
Message-ID: <1594499360.29.0.792099702339.issue41268@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41268>
_______________________________________

From report at bugs.python.org  Sat Jul 11 16:53:36 2020
From: report at bugs.python.org (yyyyyyyan)
Date: Sat, 11 Jul 2020 20:53:36 +0000
Subject: [issue41233] Missing links to errnos on Built-in Exceptions page
In-Reply-To: <1594161566.11.0.329793156149.issue41233@roundup.psfhosted.org>
Message-ID: <1594500816.81.0.0957027965888.issue41233@roundup.psfhosted.org>


yyyyyyyan <yanorestes at hotmail.com> added the comment:

Thank you, @terry.reedy! Can you point me if this is defined in some written document I can check? Or is it an internal rule everyone kinda finds out by themselves?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41233>
_______________________________________

From report at bugs.python.org  Sat Jul 11 16:57:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Jul 2020 20:57:09 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594501029.55.0.620322538614.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks for joining in! How do you do incremental parsing with LL1 currently? FWIW I found https://ohmlang.github.io/pubs/sle2017/incremental-packrat-parsing.pdf which may have some useful ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Sat Jul 11 17:04:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 21:04:00 +0000
Subject: [issue41266] IDLE call hints and completions confused by ints and
 floats
In-Reply-To: <1594370995.93.0.883531134582.issue41266@roundup.psfhosted.org>
Message-ID: <1594501440.51.0.249453071249.issue41266@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Neither '1 .bit_length()' (space required) nor '1.3.hex()', both legal syntax, get either proper completions or call hints.  Neither does the erroneous syntax '1.bit_length'. This suggests that the backwards parsing from the final '.' could be improved.  The first place to look would be whatever common code there is in hyperparser.

(Side note: something.x<tab> tabs if no completions are found.  Should inproved doc on this.)

----------
title: Wrong hint when class methods and builtins named same -> IDLE call hints and completions confused by ints and floats
type:  -> behavior
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41266>
_______________________________________

From report at bugs.python.org  Sat Jul 11 17:19:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2020 21:19:23 +0000
Subject: [issue41233] Missing links to errnos on Built-in Exceptions page
In-Reply-To: <1594161566.11.0.329793156149.issue41233@roundup.psfhosted.org>
Message-ID: <1594502363.17.0.456788221886.issue41233@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Near the bottom of the opening page: https://devguide.python.org/#status-of-python-branches
The meaning of 'status' is explained elsewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41233>
_______________________________________

From report at bugs.python.org  Sat Jul 11 17:51:41 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Sat, 11 Jul 2020 21:51:41 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1594504301.37.0.140757022129.issue41274@roundup.psfhosted.org>


Juan Jimenez <flybd5 at gmail.com> added the comment:

How would I know if my demo is good enough to be included in that repo? Is there a guide for this, or do I just create a pull request, throw it over the fence and wait until the wolves either grunt in approval or throw it back at me in pieces? I ask because I have never participated in a repo related to as big a project as Python 3. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:46:12 2020
From: report at bugs.python.org (Tom Forbes)
Date: Sat, 11 Jul 2020 22:46:12 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
Message-ID: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>


New submission from Tom Forbes <tom at tomforb.es>:

`functools.lru_cache` has a maxsize=128 default for all functions.

If a function has no arguments then this maxsize default is redundant and should be set to `maxsize=None`:

```
@functools.lru_cache()
def function_with_no_args():
    pass
```

Currently you need to add `maxsize=None` manually, and ensure that it is also updated if you alter the function to add arguments.

----------
components: Library (Lib)
messages: 373542
nosy: Tom Forbes
priority: normal
severity: normal
status: open
title: lru_cache on 0-arity functions should default to maxsize=None
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Sat Jul 11 19:28:44 2020
From: report at bugs.python.org (yyyyyyyan)
Date: Sat, 11 Jul 2020 23:28:44 +0000
Subject: [issue41233] Missing links to errnos on Built-in Exceptions page
In-Reply-To: <1594161566.11.0.329793156149.issue41233@roundup.psfhosted.org>
Message-ID: <1594510124.78.0.0721834940958.issue41233@roundup.psfhosted.org>


yyyyyyyan <yanorestes at hotmail.com> added the comment:

Thank you so much! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41233>
_______________________________________

From report at bugs.python.org  Sat Jul 11 19:34:58 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 11 Jul 2020 23:34:58 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
In-Reply-To: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>
Message-ID: <1594510498.44.0.834700737242.issue41280@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Tom Forbes, I don't think there is a way to be sure that's the function does not take any argument. Are you worried about the lost memory when maxsize is not set?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Sat Jul 11 21:10:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 01:10:29 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
In-Reply-To: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>
Message-ID: <1594516229.8.0.754602476982.issue41280@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The number of arguments is determined when the function is called (and it may be different for every call). maxsize is specified when the function is created.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Sat Jul 11 22:43:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jul 2020 02:43:24 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
In-Reply-To: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>
Message-ID: <1594521804.69.0.589811268565.issue41280@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Sat Jul 11 22:59:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Jul 2020 02:59:16 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
In-Reply-To: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>
Message-ID: <1594522756.34.0.97290197629.issue41280@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

In 3.9, the @cache() alias is provided as a cleaner way to create an unbounded cache.?  There is no need to special case a zero-arity function.  Besides as R?mi and Serhiy have pointed out, we can't know the arity in advance.

? https://docs.python.org/3.9/library/functools.html#functools.cache

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Sun Jul 12 01:26:29 2020
From: report at bugs.python.org (yyyyyyyan)
Date: Sun, 12 Jul 2020 05:26:29 +0000
Subject: [issue41281] Wrong/missing code formats in datetime documentation
Message-ID: <1594531589.9.0.00878151530973.issue41281@roundup.psfhosted.org>


New submission from yyyyyyyan <yanorestes at hotmail.com>:

The datetime page in the docs is missing a lot of needed backquotes syntax for inline code samples. There are some wrong role links too, due to ambiguity in the text roles.

----------
assignee: docs at python
components: Documentation
messages: 373547
nosy: docs at python, eric.araujo, ezio.melotti, mdk, willingc, yyyyyyyan
priority: normal
severity: normal
status: open
title: Wrong/missing code formats in datetime documentation
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41281>
_______________________________________

From report at bugs.python.org  Sun Jul 12 01:29:56 2020
From: report at bugs.python.org (yyyyyyyan)
Date: Sun, 12 Jul 2020 05:29:56 +0000
Subject: [issue41281] Wrong/missing code formats in datetime documentation
In-Reply-To: <1594531589.9.0.00878151530973.issue41281@roundup.psfhosted.org>
Message-ID: <1594531796.73.0.67243678606.issue41281@roundup.psfhosted.org>


Change by yyyyyyyan <yanorestes at hotmail.com>:


----------
keywords: +patch
pull_requests: +20595
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21447

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41281>
_______________________________________

From report at bugs.python.org  Sun Jul 12 04:30:25 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 12 Jul 2020 08:30:25 +0000
Subject: [issue41282] Deprecate and remove distutils
Message-ID: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Setuptools has adopted distutils as outlined in [pypa/packaging-problems#127](https://github.com/pypa/packaging-problems/issues/127). Although there are some straggling issues, the current release of Setuptools fully obviates distutils if a certain environment variable is set. Soon, that behavior will be default.

Additionally, the distutils codebase remains maintained at [pypa/distutils](https://github.com/pypa/distutils) in a form suitable for releasing as a third-party package, should the need arise (i.e. pip install distutils).

The plan now is to freeze, deprecate, and in Python N + 0.1, remove distutils.

Already, Setuptools is identifying emergent bugs and other defects in distutils and providing fixes for them (issue41207, [pypa/setuptools#2212](https://github.com/pypa/setuptools/issues/2212)). Keeping these changes in sync across three repos and different supported versions is tedious, so I'd like to move forward with the deprecation process as soon as possible.

----------
components: Distutils
messages: 373548
nosy: dstufft, eric.araujo, jaraco
priority: normal
severity: normal
status: open
title: Deprecate and remove distutils
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Sun Jul 12 04:34:02 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 12 Jul 2020 08:34:02 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594542842.85.0.7431924166.issue41282@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +ncoghlan, paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Sun Jul 12 04:33:17 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 12 Jul 2020 08:33:17 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594542797.17.0.2015777765.issue41282@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

?ukasz, would it be possible to add the deprecation warning and documented deprecation to Python 3.9?

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Sun Jul 12 04:50:51 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 12 Jul 2020 08:50:51 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594543851.77.0.542517170969.issue41282@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Sun Jul 12 05:06:23 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Jul 2020 09:06:23 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594544783.01.0.222729100062.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20596
pull_request: https://github.com/python/cpython/pull/21448

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 05:06:59 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Jul 2020 09:06:59 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594544819.35.0.392124713965.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20597
pull_request: https://github.com/python/cpython/pull/21449

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 05:13:14 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Jul 2020 09:13:14 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594545194.54.0.0747266479131.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20598
pull_request: https://github.com/python/cpython/pull/21450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 05:17:16 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jul 2020 09:17:16 +0000
Subject: [issue27534] IDLE: Reduce number and time for user process imports
In-Reply-To: <1468711156.27.0.318866145341.issue27534@psf.upfronthosting.co.za>
Message-ID: <1594545436.23.0.292421054523.issue27534@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I'm going to close the PR for this as the change is out of date with newer changes to fetch_completions and fetch_completions is being rewritten for #37766.  It would be easiest to revisit this once the other changes to fetch_completions are set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27534>
_______________________________________

From report at bugs.python.org  Sun Jul 12 05:20:32 2020
From: report at bugs.python.org (Adam Eltawla)
Date: Sun, 12 Jul 2020 09:20:32 +0000
Subject: [issue41283] The parameter name for imghdr.what in the documentation
 is wrong
Message-ID: <1594545631.96.0.481890798822.issue41283@roundup.psfhosted.org>


New submission from Adam Eltawla <bekerpico at gmail.com>:

I noticed the parameter name for imghdr.what in the documentation is wrong

Link: https://docs.python.org/3.8/library/imghdr.html?highlight=imghdr
function imghdr.what(filename, h=None)

In reality:
def what(file, h=None):

It is 'file' not 'filename'.

----------
assignee: docs at python
components: Documentation
messages: 373551
nosy: aeltawela, docs at python
priority: normal
severity: normal
status: open
title: The parameter name for imghdr.what in the documentation is wrong
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41283>
_______________________________________

From report at bugs.python.org  Sun Jul 12 06:00:29 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Jul 2020 10:00:29 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594548029.07.0.0429004642006.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20599
pull_request: https://github.com/python/cpython/pull/21451

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 06:05:31 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Jul 2020 10:05:31 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594548331.55.0.8434663136.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20600
pull_request: https://github.com/python/cpython/pull/21452

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 06:12:20 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jul 2020 10:12:20 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594548740.74.0.000300097930683.issue40275@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy:  -vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 08:04:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 12:04:22 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1594555462.45.0.235957502208.issue40275@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Jul 12 09:20:43 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Sun, 12 Jul 2020 13:20:43 +0000
Subject: [issue41284] High Level API for json file parsing
Message-ID: <1594560043.3.0.756696786523.issue41284@roundup.psfhosted.org>


New submission from Wansoo Kim <rladhkstn8 at gmail.com>:

Many Python users use the following snippets to read Json File.

```
with oepn(filepath, 'r') as f:
    data = json.load(f)
```

I suggest providing this snippet as a function.


```
data = json.read(filepath)
```

Reading Json is very frequent task for python users. I think it is worth providing this with the High Level API.

----------
components: Library (Lib)
messages: 373552
nosy: ys19991
priority: normal
severity: normal
status: open
title: High Level API for json file parsing
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41284>
_______________________________________

From report at bugs.python.org  Sun Jul 12 09:25:31 2020
From: report at bugs.python.org (Wansoo Kim)
Date: Sun, 12 Jul 2020 13:25:31 +0000
Subject: [issue41284] High Level API for json file parsing
In-Reply-To: <1594560043.3.0.756696786523.issue41284@roundup.psfhosted.org>
Message-ID: <1594560331.22.0.480455153223.issue41284@roundup.psfhosted.org>


Change by Wansoo Kim <rladhkstn8 at gmail.com>:


----------
keywords: +patch
pull_requests: +20601
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41284>
_______________________________________

From report at bugs.python.org  Sun Jul 12 09:28:50 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 12 Jul 2020 13:28:50 +0000
Subject: [issue41284] High Level API for json file parsing
In-Reply-To: <1594560043.3.0.756696786523.issue41284@roundup.psfhosted.org>
Message-ID: <1594560530.5.0.303995355049.issue41284@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi, using a file object is very common as it makes it possible to use something that is not a file, like an HTTP request or something already in memory. It makes the module serializing / de-serializing the data completely agnostic with regard to the actual physical storage which has some advantages, for example it will not raise FileNotFound.

If you want a oneliner to load data you already can use:



    with open(filepath) as f: data = json.load(f)

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41284>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:23:24 2020
From: report at bugs.python.org (Michiel de Hoon)
Date: Sun, 12 Jul 2020 14:23:24 +0000
Subject: [issue41285] memoryview does not support subclassing
Message-ID: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>


New submission from Michiel de Hoon <mjldehoon at yahoo.com>:

Currently memoryview does not support subclassing:

>>> class B(memoryview): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'memoryview' is not an acceptable base type


Subclassing memoryview can be useful when
- class A supports the buffer protocol;
- class B wraps class A and should support the buffer protocol provided by class A;
- class A does not support subclassing.

In this situation,

class B(memoryview):
    def __new__(cls, a):
        return super(B, cls).__new__(cls, a)

where a is an instance of class A, would let instances of B support the buffer protocol provided by a.


Is there any particular reason why memoryview does not support subclassing?

----------
components: C API
messages: 373554
nosy: mdehoon
priority: normal
severity: normal
status: open
title: memoryview does not support subclassing
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/issue41285>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:35:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jul 2020 14:35:29 +0000
Subject: [issue41284] High Level API for json file parsing
In-Reply-To: <1594560043.3.0.756696786523.issue41284@roundup.psfhosted.org>
Message-ID: <1594564529.35.0.863790041996.issue41284@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There was a previous issue to support filepath for json.load https://bugs.python.org/issue36378 . This just expands the json API that could already be done using one more operation.

----------
nosy: +ezio.melotti, rhettinger, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41284>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:37:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jul 2020 14:37:24 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594564644.7.0.775823101356.issue41285@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:38:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jul 2020 14:38:29 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1594476433.53.0.621275594996.issue41208@roundup.psfhosted.org>
Message-ID: <CABqyc3w6Brj4bA_dAJCPBu0WRcfAUp+v3e=6R90CgmUQtGz5sA@mail.gmail.com>


STINNER Victor <vstinner at python.org> added the comment:

By design, it is trivial to run arbritrary Python code using pickle. There
is no need to exploit a segfault for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:45:23 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Sun, 12 Jul 2020 14:45:23 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594565123.06.0.21254483975.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

There are many online Python interpreters, we can use this malicious file to escape their sandboxes and get control of their Docker container or system (and abuse them, for example, to conduct a DoS attack), as their fully trust that Python doesn't generate segfault.  
For example, the following code clearly kills the interpreter (and a shellcode can be attached), even though, they have protection mechanisms for file access and many other things.

-----------
https://www.programiz.com/python-programming/online-compiler/
-----------

import io
import marshal



hex_string = "FBE901000000DA0136E90209000072010000007203000000DA0168A90372010000007205000000DA026161DA026A6A7BDA0278785B020000007201000000DA01353030DA0170E7E10B930189E4414130"
myb = bytes.fromhex(hex_string)
f = io.BytesIO(myb)
print(f)
data = marshal.load(f)
print(data)
print('We have segfault but we cannot see!')
-------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:52:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jul 2020 14:52:53 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1594565123.06.0.21254483975.issue41208@roundup.psfhosted.org>
Message-ID: <CABqyc3z0bUiW5T7oz5i2WHv1KN3pYVddBAginZg-HkZ9_qMLRQ@mail.gmail.com>


STINNER Victor <vstinner at python.org> added the comment:

This bug tracker is not the right place to report issues of third party web
services. I don't see anything wrong with Python according to Python Threat
Model:
https://python-security.readthedocs.io/security.html#python-security-model

That's why pickle starts with a big warning about the lack of security.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 11:52:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 15:52:30 +0000
Subject: [issue41284] High Level API for json file parsing
In-Reply-To: <1594560043.3.0.756696786523.issue41284@roundup.psfhosted.org>
Message-ID: <1594569150.35.0.374635139675.issue41284@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

json.load() is already a high level API. json.JSONDecoder is more low level API.

Not every two lines of code should be added as a function in the stdlib. Also, such API would be too complex because you would need to combine parameters of open() (8 parameters) and json.load() (7 parameters). If you use these two lines many times in your code you can just add a simple function that supports only options needed for you.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41284>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:01:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:01:13 +0000
Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za>
Message-ID: <1594569673.11.0.622449167868.issue20181@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b7047e59a40649d81061acf0044e74cfd426f064 by Zackery Spytz in branch 'master':
bpo-20181: Convert the readline module to the Argument Clinic (#14326)
https://github.com/python/cpython/commit/b7047e59a40649d81061acf0044e74cfd426f064


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20181>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:08:26 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 12 Jul 2020 16:08:26 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594570106.96.0.308459212924.issue41285@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
versions:  -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/issue41285>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:11:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:11:18 +0000
Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8
 files
In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za>
Message-ID: <1594570278.68.0.582287474876.issue20175@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 545b54d2abbc7970aa66b179a18ff2ac4440a8f9 by Zackery Spytz in branch 'master':
bpo-20175: Convert Modules/_multiprocessing to the Argument Clinic (GH-14245)
https://github.com/python/cpython/commit/545b54d2abbc7970aa66b179a18ff2ac4440a8f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20175>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:13:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:13:12 +0000
Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za>
Message-ID: <1594570392.52.0.690787063529.issue20181@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20181>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:13:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:13:44 +0000
Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8
 files
In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za>
Message-ID: <1594570424.68.0.187316686374.issue20175@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20175>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:14:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:14:39 +0000
Subject: [issue41187] Convert the _msi module to Argument Clinic
In-Reply-To: <1593622165.78.0.318018387297.issue41187@roundup.psfhosted.org>
Message-ID: <1594570479.29.0.475156807018.issue41187@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41187>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:15:24 2020
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 12 Jul 2020 16:15:24 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
Message-ID: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>


New submission from Bo?tjan Mejak <bostjan.xperia at gmail.com>:

The platform module does not offer to check whether a processor supports the POPCNT or BMI/BMI2 processor instructions. Am I missing something or is it actually missing this feature?

----------
components: Library (Lib)
messages: 373563
nosy: PedanticHacker
priority: normal
severity: normal
status: open
title: Built-in platform module does not offer to check for processor instructions
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/issue41286>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:15:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:15:23 +0000
Subject: [issue41146] Convert signal.default_int_handler() to Argument Clinic
In-Reply-To: <1593342043.08.0.492755229257.issue41146@roundup.psfhosted.org>
Message-ID: <1594570523.99.0.958361709778.issue41146@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b0689ae7f9d904bc2126994aedbc552f03479e40 by Serhiy Storchaka in branch 'master':
bpo-41146: Convert signal.default_int_handler() to Argument Clinic (GH-21197)
https://github.com/python/cpython/commit/b0689ae7f9d904bc2126994aedbc552f03479e40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41146>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:15:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 16:15:51 +0000
Subject: [issue41146] Convert signal.default_int_handler() to Argument Clinic
In-Reply-To: <1593342043.08.0.492755229257.issue41146@roundup.psfhosted.org>
Message-ID: <1594570551.55.0.541040541555.issue41146@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41146>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:35:45 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 12 Jul 2020 16:35:45 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594571745.43.0.868524263568.issue41208@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Linux containers like Docker are not a security boundary. They are a merely a mechanism to package, deliver, and run software. Dan Walsh coined the phrase "Containers Don't Contain" a while ago. It's possible to tighten security of containers. This starts at "Don't execute arbitrary and potentially malicious code".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 12:43:02 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 12 Jul 2020 16:43:02 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594572182.3.0.462051751813.issue41286@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Python's standard library doesn't aim to solve all problems. Python also supports a lot of platforms and CPU architectures. We'd have to implement this on major platforms like BSD, Linux, and Windows as well as other supported platforms like AIX or VMS multiplied by all support CPUs architectures like X86, X86_64, multiple ARMs, ...

This sounds like a feature that can be implemented in a PyPI package.

----------
nosy: +christian.heimes
versions:  -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/issue41286>
_______________________________________

From report at bugs.python.org  Sun Jul 12 15:02:01 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 12 Jul 2020 19:02:01 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594580521.66.0.695934343741.issue41286@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

What would you use this information for, if it were available from Python code?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Sun Jul 12 15:49:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 19:49:13 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594583353.97.0.788172950835.issue41208@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It depends. pickle is not vulnerable to the kind of error reported in this issue. If you find some way to crash Python specific to pickle it will likely be fixed if it is possible without significant performance or memory cost. If it depends on arbitrary code execution, it is not a pickle issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 15:59:55 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 12 Jul 2020 19:59:55 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593549875.63.0.81357373837.issue41176@roundup.psfhosted.org>
Message-ID: <1594583995.2.0.878057560266.issue41176@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I have just finished reviewing the proposed PR, and am happy with the content. During the process of developing the PR, we established that the behaviour that should be deprecated is the error after a second of waiting in a thread. Instead, on `WaitForMainloop` removal, we should pass straight through and use the tcl queue to wait for mainloop.

@Serhiy, is waiting for the tcl queue acceptable behaviour? It seemed to behave correctly during my tests and if it is acceptable, both me and Richard would really appreciate your review of the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41176>
_______________________________________

From report at bugs.python.org  Sun Jul 12 16:15:31 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Sun, 12 Jul 2020 20:15:31 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594584931.29.0.345883922169.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

@serhiy.storchaka you name it, you have it. The following code generates a segfault on the Pickle module [it's a crafted datetime object] (Python 3.10.0a0 (heads/master:b40e434, Jul  4 2020), Python 3.6.11 and Python 3.7.2):

import io
import pickle


hex_string = "8004952A000000000000008C086461746574696D65948C086461746574696D65949388430A07B2010100000000000092059452942E"
myb = bytes.fromhex(hex_string)
f = io.BytesIO(myb)
print(f)
data = pickle.load(f)
print(data)
print('We have segfault but we cannot see!')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 16:27:08 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 12 Jul 2020 20:27:08 +0000
Subject: [issue41257] mimetypes.guess_extension('video/x-matroska') return
 wrong value
In-Reply-To: <1594301014.01.0.923541225883.issue41257@roundup.psfhosted.org>
Message-ID: <1594585628.41.0.0213193037681.issue41257@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

This looks the same as issue38656, feel free to re-open if its not.

----------
nosy: +ammar2
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41257>
_______________________________________

From report at bugs.python.org  Sun Jul 12 16:34:43 2020
From: report at bugs.python.org (Sergei Izmailov)
Date: Sun, 12 Jul 2020 20:34:43 +0000
Subject: [issue41287] __doc__ attribute is not set in property-derived classes
Message-ID: <1594586083.6.0.902653661287.issue41287@roundup.psfhosted.org>


New submission from Sergei Izmailov <sergei.a.izmailov at gmail.com>:

MRE: 

class Property(property):
    pass

print(Property(None, None, None, "hello").__doc__)

Expected: 
hello

Actual:
None

----------
messages: 373571
nosy: Sergei Izmailov
priority: normal
severity: normal
status: open
title: __doc__ attribute is not set in property-derived classes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41287>
_______________________________________

From report at bugs.python.org  Sun Jul 12 17:30:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 21:30:13 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594589413.34.0.336338132297.issue41208@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you. Indeed, it is a pickle specific crash. Please open a new issue and I'll provide a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 17:36:09 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Sun, 12 Jul 2020 21:36:09 +0000
Subject: [issue41288] Pickle crashes using a crafted datetime object
Message-ID: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>


New submission from Iman Sharafodin <iman.sharafodin at gmail.com>:

The following code generates a segfault on the Pickle module [it's a crafted datetime object] (Python 3.10.0a0 (heads/master:b40e434, Jul  4 2020), Python 3.6.11 and Python 3.7.2):

import io
import pickle


hex_string = "8004952A000000000000008C086461746574696D65948C086461746574696D65949388430A07B2010100000000000092059452942E"
myb = bytes.fromhex(hex_string)
f = io.BytesIO(myb)
print(f)
data = pickle.load(f)
print(data)
print('We have segfault but we cannot see!')

----------
components: Interpreter Core
messages: 373573
nosy: Iman Sharafodin
priority: normal
severity: normal
status: open
title: Pickle crashes using a crafted datetime object
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 12 17:36:59 2020
From: report at bugs.python.org (Iman Sharafodin)
Date: Sun, 12 Jul 2020 21:36:59 +0000
Subject: [issue41208] An exploitable segmentation fault in marshal module
In-Reply-To: <1593863789.9.0.238701347914.issue41208@roundup.psfhosted.org>
Message-ID: <1594589819.19.0.829026427911.issue41208@roundup.psfhosted.org>


Iman Sharafodin <iman.sharafodin at gmail.com> added the comment:

@serhiy.storchaka Thank you. Please find it here https://bugs.python.org/issue41288 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41208>
_______________________________________

From report at bugs.python.org  Sun Jul 12 17:38:55 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 12 Jul 2020 21:38:55 +0000
Subject: [issue41288] Pickle crashes using a crafted datetime object
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594589935.56.0.910727162849.issue41288@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

datetime_new assumes that args is a tuple. load_newobj_ex() doesn't check that args is a tuple and kwargs is a dictionary. The demo exploit passes ``True`` as args, which triggers a segfault in PyTuple_GET_SIZE in datetime_new.

#0  datetime_new (type=0x7fffea5d2740 <PyDateTime_DateTimeType>, args=True, kw=b'\x07\xb2\x01\x01\x00\x00\x00\x00\x00\x00') at /usr/src/debug/python3-3.8.3-2.fc32.x86_64/Modules/_datetimemodule.c:4737
#1  0x00007fffea637b1e in load_newobj_ex (self=0x7fffea7a7820) at /usr/src/debug/python3-3.8.3-2.fc32.x86_64/Modules/_pickle.c:6008
#2  0x00007fffea632e7a in load (self=0x7fffea7a7820) at /usr/src/debug/python3-3.8.3-2.fc32.x86_64/Modules/_pickle.c:6943
#3  0x00007fffea63795e in _pickle_load_impl (module=<optimized out>, buffers=0x0, errors=0x7fffea639149 "strict", encoding=0x7fffea6391fa "ASCII", fix_imports=1, file=<_io.BytesIO at remote 0x7fffea888180>)
    at /usr/src/debug/python3-3.8.3-2.fc32.x86_64/Modules/_pickle.c:1688
#4  _pickle_load (module=<optimized out>, args=<optimized out>, nargs=<optimized out>, kwnames=<optimized out>) at /usr/src/debug/python3-3.8.3-2.fc32.x86_64/Modules/clinic/_pickle.c.h:731
#5  0x00007ffff7bd1ced in cfunction_vectorcall_FASTCALL_KEYWORDS (func=<built-in method load of module object at remote 0x7fffea680270>, args=<optimized out>, nargsf=<optimized out>, kwnames=0x0)
    at /usr/src/debug/python3-3.8.3-2.fc32.x86_64/Objects/methodobject.c:437

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 12 18:00:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Jul 2020 22:00:02 +0000
Subject: [issue41288] Pickle crashes using a crafted datetime object
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594591202.99.0.772207337096.issue41288@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
components: +Extension Modules -Interpreter Core
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 12 18:04:37 2020
From: report at bugs.python.org (Rishi)
Date: Sun, 12 Jul 2020 22:04:37 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594591477.11.0.647937663605.issue39017@roundup.psfhosted.org>


Change by Rishi <rishi93dev at gmail.com>:


----------
keywords: +patch
pull_requests: +20602
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21454

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Sun Jul 12 18:10:05 2020
From: report at bugs.python.org (Rishi)
Date: Sun, 12 Jul 2020 22:10:05 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594591805.45.0.817386584705.issue39017@roundup.psfhosted.org>


Rishi <rishi93dev at gmail.com> added the comment:

Thank you. I have signed the CLA agreement. I have pushed my code changes and also written a testcase for this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Sun Jul 12 19:56:17 2020
From: report at bugs.python.org (Neil Godber)
Date: Sun, 12 Jul 2020 23:56:17 +0000
Subject: [issue41289] '%' character in help= for argparse causes ValueError:
 incomplete format
Message-ID: <1594598177.06.0.634893124159.issue41289@roundup.psfhosted.org>


New submission from Neil Godber <njgodber at gmail.com>:

'%' character in help= for argparse causes ValueError: incomplete format. I am attempting to use the percentage character in my help string but get the above error. Presumably argparse assumes % denotes formatting when this is not the case. I have tried f-strings, escape and raw strings, none of which rectify the issue. The only solution is that dev's cannot use % character in argpase help strings which is something of an oddity.

----------
components: Interpreter Core
messages: 373578
nosy: Neil Godber
priority: normal
severity: normal
status: open
title: '%' character in help= for argparse causes ValueError: incomplete format
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41289>
_______________________________________

From report at bugs.python.org  Sun Jul 12 20:17:43 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Jul 2020 00:17:43 +0000
Subject: [issue41289] '%' character in help= for argparse causes ValueError:
 incomplete format
In-Reply-To: <1594598177.06.0.634893124159.issue41289@roundup.psfhosted.org>
Message-ID: <1594599463.34.0.882707316031.issue41289@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Did you try doubling the % char?


help='%%-age of the value'

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41289>
_______________________________________

From report at bugs.python.org  Sun Jul 12 21:17:23 2020
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 13 Jul 2020 01:17:23 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594603043.7.0.262139134434.issue41286@roundup.psfhosted.org>


Bo?tjan Mejak <bostjan.xperia at gmail.com> added the comment:

This feature is needed for a chess GUI application because the Stockfish chess engine is offered in different builds: a build that supports the POPCNT processor instruction and a build that doesn't, a build that supports the BMI/BMI2 processor instruction set, a 32-bit build and a 64-bit build, also a Windows build and a Linux build.

Then the chess GUI application can check if the processor supports the POPCNT instruction or the BMI/BMI2 processor instruction set and can load an appropriate Stockfish build to analyze a chess game or play against a human chess player by using the appropriate Stockfish build for the machine the chess GUI application is running on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:21:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jul 2020 02:21:14 +0000
Subject: [issue41287] __doc__ attribute is not set in property-derived classes
In-Reply-To: <1594586083.6.0.902653661287.issue41287@roundup.psfhosted.org>
Message-ID: <1594606874.93.0.12051732958.issue41287@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41287>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:25:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jul 2020 02:25:24 +0000
Subject: [issue41288] Pickle crashes using a crafted datetime object
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594607124.03.0.910543333932.issue41288@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:26:37 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jul 2020 02:26:37 +0000
Subject: [issue41289] '%' character in help= for argparse causes ValueError:
 incomplete format
In-Reply-To: <1594598177.06.0.634893124159.issue41289@roundup.psfhosted.org>
Message-ID: <1594607197.37.0.706239443998.issue41289@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41289>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:34:03 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Mon, 13 Jul 2020 02:34:03 +0000
Subject: [issue41210] Docs: More description of reason about LZMA1 data
 handling with FORMAT_ALONE
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594607643.91.0.354553409074.issue41210@roundup.psfhosted.org>


Hiroshi Miura <miurahr at linux.com> added the comment:

Lasse Collin gives me explanation of LZMA1 data format and suggestion how to implement.

I'd like to change an issue to a documentation issue to add more description about limitation on FORMAT_ALONE and LZMA1.

A suggestion from Lasse is as follows:

> liblzma cannot be used to decode data from .7z files except in certain
> cases. This isn't a bug, it's a missing feature.
>
> The raw encoder and decoder APIs only support streams that contain an
> end of payload marker (EOPM) alias end of stream (EOS) marker. .7z
> files use LZMA1 without such an end marker. Instead, the end is handled
> by the decoder knowing the exact uncompressed size of the data.
>
> The API of liblzma supports LZMA1 without end marker via
> lzma_alone_decoder(). That API can be abused to properly decode raw
> LZMA1 with known uncompressed size by feeding the decoder a fake 13-byte
> header. Everything else in the public API requires some end marker.
>
> Decoding LZMA1 without BCJ or other extra filters from .7z with
> lzma_raw_decoder() kind of works but you will notice that it will never
> return LZMA_STREAM_END, only LZMA_OK. This is because it will never see
> an end marker. A minor downside is that it won't then do a small
> integrity check at the end either (one variable in the range decoder
> state will be 0 at the end of any valid LZMA1 stream);
> lzma_alone_decoder() does this check even when end marker is missing.
>
> If you use lzma_raw_decoder() for end-markerless LZMA1, make sure that
> you never give it more output space than the real uncompressed size. In
> rare cases this could result in extra output or an error since the
> decoder would try to decode more output using the input it has gotten
> so far. Overall I think the hack with lzma_alone_decoder() is a better
> way with the current API.
>
> BCJ filters process the input data in chunks of a few bytes long, thus
> they need to hold a few bytes of look-ahead buffer. With some filters
> like ARM the look-ahead is aligned and if the uncompressed size is a
> multiple of this alignment, lzma_raw_decoder() will give you all the
> data even when the LZMA1 layer doesn't have an end marker. The x86
> filter has one-byte alignment but needs to see five bytes from the
> future before producing output. When LZMA1 layer doesn't return
> LZMA_STREAM_END, the x86 filter doesn't know that the end was reached
> and cannot flush the last bytes out.
>
> Using liblzma to decode .7z works in these cases:
>
> - LZMA1 using a fake 13-byte header with lzma_alone_decoder():
>
> 1 byte LZMA properties byte that encodes lc/lp/pb
> 4 bytes dictionary size as little endian uint32_t
> 8 bytes uncompressed size as little endian uint64_t;
> UINT64_MAX means unknown and then (and only then)
> EOPM must be present

----------
title: LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is paticular LZMA+BCJ  data -> Docs: More description of reason about LZMA1 data handling with FORMAT_ALONE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Sun Jul 12 23:05:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 13 Jul 2020 03:05:53 +0000
Subject: [issue41276] Min / Max returns different values depending on
 parameter order
In-Reply-To: <1594440122.62.0.379783406728.issue41276@roundup.psfhosted.org>
Message-ID: <1594609553.17.0.531080861513.issue41276@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Calvin, min and max are builtin functions and part of 'Interpreter Core'.  Confusing IDLE with Python is common for beginners who use IDLE.  Do you think I could reduce the confusion by somehow changing the message printed at the top of Shell, before '>>>'?

----------
assignee: terry.reedy -> 
components: +Interpreter Core -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41276>
_______________________________________

From report at bugs.python.org  Mon Jul 13 00:24:42 2020
From: report at bugs.python.org (Anatol Pomozov)
Date: Mon, 13 Jul 2020 04:24:42 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1594614282.15.0.637748024032.issue37095@roundup.psfhosted.org>


Anatol Pomozov <anatol.pomozov at gmail.com> added the comment:

Is there any progress with this feature development?

Arch Linux uses Python tar library for its toolset. Arch devs are looking to add ZSTD support to the toolset but it needs this feature to be implemented.

----------
nosy: +Anatol Pomozov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Mon Jul 13 00:24:57 2020
From: report at bugs.python.org (Neil Godber)
Date: Mon, 13 Jul 2020 04:24:57 +0000
Subject: [issue41289] '%' character in help= for argparse causes ValueError:
 incomplete format
In-Reply-To: <1594598177.06.0.634893124159.issue41289@roundup.psfhosted.org>
Message-ID: <1594614297.67.0.988946560004.issue41289@roundup.psfhosted.org>


Neil Godber <njgodber at gmail.com> added the comment:

Hi, yes I did just then and indeed this worked. Wasn't aware of this. Further, curiously I am no longer able recreate this issue so I will close this for now. Sorry for the bother.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41289>
_______________________________________

From report at bugs.python.org  Mon Jul 13 01:40:27 2020
From: report at bugs.python.org (Calvin Davis)
Date: Mon, 13 Jul 2020 05:40:27 +0000
Subject: [issue41276] Min / Max returns different values depending on
 parameter order
In-Reply-To: <1594440122.62.0.379783406728.issue41276@roundup.psfhosted.org>
Message-ID: <1594618827.04.0.166947008291.issue41276@roundup.psfhosted.org>


Calvin Davis <mynameiscalvindavis at gmail.com> added the comment:

You say that confusing IDLE with Python is common for beginners, do you mean to suggest that IDLE isn't a Python interpreter? I know IDLE is essentially just an IDE and distinctly different than the python shell, but I wasn't aware the differences would affect anything. I expect my sample code would work the same in IDLE or a python file, no confusion there.

I guess I'm not sure what you mean by reducing confusion, because to me IDLE and the python shell are similar enough, and both distinctly different than executing a .py file, though both should have the same behavior right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41276>
_______________________________________

From report at bugs.python.org  Mon Jul 13 02:03:56 2020
From: report at bugs.python.org (Aron Podrigal)
Date: Mon, 13 Jul 2020 06:03:56 +0000
Subject: [issue27777] cgi.FieldStorage can't parse simple body with
 Content-Length and no Content-Disposition
In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>
Message-ID: <1594620236.04.0.33748056484.issue27777@roundup.psfhosted.org>


Change by Aron Podrigal <aronp at guaranteedplus.com>:


----------
pull_requests: +20604
pull_request: https://github.com/python/cpython/pull/21457

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27777>
_______________________________________

From report at bugs.python.org  Mon Jul 13 03:28:23 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jul 2020 07:28:23 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594625303.65.0.0976148723844.issue41282@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

So what is the plan to continue to support building cpython itself which depends on Distutils? Currently the build bootstraps itself without the aid of an existing Python interpreter instance. There would also be major impacts across the whole cpython development process. For example, there are many open Distutils issues in the bugs.python.org bug tracker. We need a plan on how those are to be handled (and that should take into account the expected transition from b.p.o to GitHub issues).  People will continue to submit issues agains Distutils there so triage team members and core developers need to know how to handle such issues.  What if an issue applies also or only to a previous release branch (i.e. where Distutils is still in the repo)?  What about Distutils documentation in the Python docset?  THose are just some off the top of my head.

I don't think any of these issues are necessarily blockers but they need to be planned for and reviewed.  I think a PEP is definitely in order for a change of this magnitude.

----------
nosy: +ned.deily, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 03:29:37 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jul 2020 07:29:37 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594625377.79.0.364024941661.issue41282@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 04:21:45 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 13 Jul 2020 08:21:45 +0000
Subject: [issue41128] Signal handlers should not hang during blocked main
 thread
In-Reply-To: <1593192889.65.0.44895771655.issue41128@roundup.psfhosted.org>
Message-ID: <1594628505.85.0.954682119801.issue41128@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pitrou, serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41128>
_______________________________________

From report at bugs.python.org  Mon Jul 13 04:41:46 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 13 Jul 2020 08:41:46 +0000
Subject: [issue41176] revise Tkinter mainloop dispatching flag behavior
In-Reply-To: <1593549875.63.0.81357373837.issue41176@roundup.psfhosted.org>
Message-ID: <1594629706.42.0.0509701612767.issue41176@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Apologies, it is not waiting for the tcl queue and instead the call waits indefinitely for `Tcl_ConditionWait` (tkinter adds it to the queue and then waits for the command to finish executing). Do we need some mechanism to alert people after a second, for example, that the thread is waiting for the mainloop to come up?

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41176>
_______________________________________

From report at bugs.python.org  Mon Jul 13 05:07:40 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Jul 2020 09:07:40 +0000
Subject: [issue41289] '%' character in help= for argparse causes ValueError:
 incomplete format
In-Reply-To: <1594598177.06.0.634893124159.issue41289@roundup.psfhosted.org>
Message-ID: <1594631260.48.0.447621680329.issue41289@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

It's using normal %-formatting, so the rules applied are in https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

The last line of the last table in that section mentions literal % characters. I realize it's sort of hard to dig this up if you're just interested in argparse.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41289>
_______________________________________

From report at bugs.python.org  Mon Jul 13 06:28:31 2020
From: report at bugs.python.org (Janae)
Date: Mon, 13 Jul 2020 10:28:31 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594636111.24.0.688312459802.issue33840@roundup.psfhosted.org>


Janae <goldgold09.8123 at gmail.com> added the comment:

All works are very interesting. thanks, to post and your works.
https://apkgreat.com/fifa-14-apk/

----------
nosy: +Janae147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Mon Jul 13 06:44:22 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jul 2020 10:44:22 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594637062.63.0.573665067096.issue33840@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373589

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Mon Jul 13 06:44:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jul 2020 10:44:44 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1594637084.41.0.185293601507.issue33840@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy:  -Janae147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Mon Jul 13 06:45:13 2020
From: report at bugs.python.org (Ma Lin)
Date: Mon, 13 Jul 2020 10:45:13 +0000
Subject: [issue41210] Docs: More description of reason about LZMA1 data
 handling with FORMAT_ALONE
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594637113.86.0.240725463326.issue41210@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

It is better to raise a warning when using problematic combination.

But IMO either "raising a warning" or "adding more description to doc" is too dependent on the implementation detail of liblzma.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Mon Jul 13 06:54:16 2020
From: report at bugs.python.org (Janae)
Date: Mon, 13 Jul 2020 10:54:16 +0000
Subject: [issue41210] Docs: More description of reason about LZMA1 data
 handling with FORMAT_ALONE
In-Reply-To: <1593913885.93.0.828443713776.issue41210@roundup.psfhosted.org>
Message-ID: <1594637656.89.0.898355327753.issue41210@roundup.psfhosted.org>


Janae <goldgold09.8123 at gmail.com> added the comment:

Here is a BCJ only CFFI test project.
https://apkgreat.com/fifa-14-apk/
All works are very interesting. thanks, to post and your works.

----------
nosy: +Janae147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41210>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:22:25 2020
From: report at bugs.python.org (Allayna Wilson)
Date: Mon, 13 Jul 2020 11:22:25 +0000
Subject: [issue41290] ipaddress module doesn't recognize 100.64.0.0/10 as a
 private network
Message-ID: <1594639345.1.0.636804345302.issue41290@roundup.psfhosted.org>


New submission from Allayna Wilson <allaynawilson at gmail.com>:

import IPv4Address as n4

In [10]: n4('100.64.0.0/24').is_private                                                                                     
Out[10]: False

In [11]: n4('100.64.0.0/10').is_private                                                                                     
Out[11]: False

https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4

keep this on the dl though I don't want anybody else using this /10. I'm tired of people's crap always overlapping with my private networks.

----------
components: Extension Modules, Library (Lib)
messages: 373592
nosy: Allayna Wilson
priority: normal
severity: normal
status: open
title: ipaddress module doesn't recognize 100.64.0.0/10 as a private network
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/issue41290>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:32:16 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 13 Jul 2020 11:32:16 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1594639936.02.0.549177542756.issue37095@roundup.psfhosted.org>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
versions: +Python 3.10 -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:34:51 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 13 Jul 2020 11:34:51 +0000
Subject: [issue40746] test_gdb failing on 32-bit armv7l when built with GCC
 -Og (fail on Raspbian on 3.9, regression from 3.8)
In-Reply-To: <1590258625.25.0.246740749681.issue40746@roundup.psfhosted.org>
Message-ID: <1594640091.02.0.444773583853.issue40746@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: 3.9.0b5, the last beta before 3.9.0, is next week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40746>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:36:00 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 13 Jul 2020 11:36:00 +0000
Subject: [issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
In-Reply-To: <1581871318.96.0.350376923794.issue39651@roundup.psfhosted.org>
Message-ID: <1594640160.93.0.416941421034.issue39651@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

We have trouble finding a Windows expert with available time to address this :/ This is missing 3.8.4 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:44:02 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 13 Jul 2020 11:44:02 +0000
Subject: [issue41290] ipaddress module doesn't recognize 100.64.0.0/10 as a
 private network
In-Reply-To: <1594639345.1.0.636804345302.issue41290@roundup.psfhosted.org>
Message-ID: <1594640642.42.0.53461165271.issue41290@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components:  -Extension Modules
nosy: +pitrou
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41290>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:44:49 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 13 Jul 2020 11:44:49 +0000
Subject: [issue40536] Addition of a "list of available time zones" function to
 zoneinfo
In-Reply-To: <1588785591.81.0.248136692657.issue40536@roundup.psfhosted.org>
Message-ID: <1594640689.01.0.86555497643.issue40536@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: next week is 3.9.0b5, the last beta before 3.9.0. Please decide what to do with the rest of the issue before then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40536>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:51:48 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 13 Jul 2020 11:51:48 +0000
Subject: [issue41290] ipaddress module doesn't recognize 100.64.0.0/10 as a
 private network
In-Reply-To: <1594639345.1.0.636804345302.issue41290@roundup.psfhosted.org>
Message-ID: <1594641108.37.0.33483525793.issue41290@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

This was an intentional change, see #17400 and specifically commit 49e012e5492c1c70690ab72a8d03a980047148b5; so I'm going to close this issue as not a bug.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41290>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:11:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jul 2020 12:11:24 +0000
Subject: [issue41288] Pickle crashes using a crafted datetime object
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594642284.28.0.0650544963357.issue41288@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20605
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21458

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:17:22 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Mon, 13 Jul 2020 12:17:22 +0000
Subject: [issue41013] test_os.test_memfd_create() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1592434332.74.0.304039490213.issue41013@roundup.psfhosted.org>
Message-ID: <1594642642.15.0.714443859624.issue41013@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

I've updated the FreeBSD CURRENT buildbot past base/r363065 [1] which implements SHM_GROW_ON_WRITE:

https://svnweb.freebsd.org/changeset/base/363065
https://reviews.freebsd.org/D25502

Also worth noting that I don't believe stable/12 (FreeBSD 12.x) will be getting this syscall (correct me if im wrong Kyle), so these tests may still fail on the FreeBSD 12.x worker, and the tests should be updated to account for that in some manner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41013>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:28:54 2020
From: report at bugs.python.org (Kyle Evans)
Date: Mon, 13 Jul 2020 12:28:54 +0000
Subject: [issue41013] test_os.test_memfd_create() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1592434332.74.0.304039490213.issue41013@roundup.psfhosted.org>
Message-ID: <1594643334.99.0.9040702002.issue41013@roundup.psfhosted.org>


Kyle Evans <kevans at FreeBSD.org> added the comment:

I can confirm that neither 12 nor 11 will be getting memfd_create; file sealing is a little more complicated to MFC, and I don't want to provide memfd_create in a place where it can't be paired with file sealing in case applications assume they come hand-in-hand and want to use sealing for freezable shm type stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41013>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:29:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jul 2020 12:29:45 +0000
Subject: [issue41288] Pickle crashes unpickling invalig NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594643385.04.0.839965934163.issue41288@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: Pickle crashes using a crafted datetime object -> Pickle crashes unpickling invalig NEWOBJ_EX opcode

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:47:54 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 13 Jul 2020 12:47:54 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594644474.08.0.870706136172.issue41288@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
title: Pickle crashes unpickling invalig NEWOBJ_EX opcode -> Pickle crashes unpickling invalid NEWOBJ_EX opcode

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:49:52 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 12:49:52 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594644592.75.0.280946140222.issue41288@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4f309abf55f0e6f8950ac13d6ec83c22b8d47bf8 by Serhiy Storchaka in branch 'master':
bpo-41288: Fix a crash in unpickling invalid NEWOBJ_EX. (GH-21458)
https://github.com/python/cpython/commit/4f309abf55f0e6f8950ac13d6ec83c22b8d47bf8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:50:15 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 12:50:15 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594644615.09.0.260311582549.issue41288@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20606
pull_request: https://github.com/python/cpython/pull/21459

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:50:24 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 12:50:24 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594644624.66.0.454820558105.issue41288@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20607
pull_request: https://github.com/python/cpython/pull/21460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:51:23 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 13 Jul 2020 12:51:23 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594644683.54.0.0649254799717.issue41288@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Ned, would you like to get this fix backported to 3.6 and 3.7?

----------
nosy: +ned.deily
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 08:56:05 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 13 Jul 2020 12:56:05 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594644965.01.0.40434544976.issue41285@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Would you be more specific about why you need that feature on the Python-ideas mailing list or "Ideas" category on discuss.python.org?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:01:41 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 13 Jul 2020 13:01:41 +0000
Subject: [issue41284] High Level API for json file parsing
In-Reply-To: <1594560043.3.0.756696786523.issue41284@roundup.psfhosted.org>
Message-ID: <1594645301.32.0.155425086361.issue41284@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

(Off topic) There is a very common mistake in this code:

```
with oepn(filepath, 'r') as f:
    data = json.load(f)
```

JSON file is encoded in UTF-8. But the default text encoding is locale encoding.

You should do this instead:

```
with oepn(filepath, 'rb') as f:
    data = json.load(f)
```

This works for legacy JSON with UTF-16 or UTF-32 (with/without BOM).too.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41284>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:05:25 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jul 2020 13:05:25 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594645525.14.0.292880056458.issue41288@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Sounds like a good idea.

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:05:51 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 13:05:51 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594645551.17.0.858982727072.issue41288@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f56c75ed53dcad4d59dff4377ae463d6b96acd3e by Miss Islington (bot) in branch '3.8':
bpo-41288: Fix a crash in unpickling invalid NEWOBJ_EX. (GH-21458)
https://github.com/python/cpython/commit/f56c75ed53dcad4d59dff4377ae463d6b96acd3e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:08:32 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 13:08:32 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594645712.71.0.0122929786021.issue41288@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20608
pull_request: https://github.com/python/cpython/pull/21461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:08:45 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 13:08:45 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594645725.93.0.746897403612.issue41288@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20609
pull_request: https://github.com/python/cpython/pull/21462

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:09:30 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jul 2020 13:09:30 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594645770.95.0.443215029199.issue41288@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 57c984fab69b862563899d2c11da7d27201f4152 by Miss Islington (bot) in branch '3.9':
bpo-41288: Fix a crash in unpickling invalid NEWOBJ_EX. (GH-21458)
https://github.com/python/cpython/commit/57c984fab69b862563899d2c11da7d27201f4152


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:04:01 2020
From: report at bugs.python.org (Giovanni Pizzi)
Date: Mon, 13 Jul 2020 14:04:01 +0000
Subject: [issue41291] Race conditions when opening and deleting a file on Mac
 OS X
Message-ID: <1594649041.52.0.898762861377.issue41291@roundup.psfhosted.org>


New submission from Giovanni Pizzi <gio.piz at gmail.com>:

Hello,

when creating deleting (with `os.remove`/`os.unlink`) a file and opening it in a different process at (almost) the same time, on Mac OS X relatively often I get a file that is empty instead of either a `FileNotFoundError` exception, or an open handle with the original content, i.e. at least one of the two operations (unlinking or opening) seems to be non-atomic.
(With empty I mean that if after I open the file (mode 'rb'), then `fhandle.read()` returns me b''.

More in particular, after quite some debugging I noticed that what happens is that if I stat the file descriptor, `st_ino` is zero.

This can reproduced very easily.
I set up a GitHub repository here: https://github.com/giovannipizzi/concurrent-delete-race-problem
with simple examples and tests (and both a Python implementation and a C implementation).
There are also GitHub Actions that run on Mac, Ubuntu and Windows, and apparently the problem exists only on Mac (and happens on all versions).

For completeness I attach also here a tar.gz with the two very short python files that just need be run in parallel - in my Mac OS X (macOS 10.14.6, 15" 2016 MacBook Pro, python 3.6) I get the error essentially at every run. 

Important: while much harder to reproduce, I can get the same error and behaviour also with the (I think equivalent) C code. 
Therefore, this seems to be more a problem with the Mac OS standard libraries?

My first question is: has anybody ever seen this problem? It seems to me quite easy to reproduce, but I'm surprised that I couldn't find any reference in the internet even after searching for various hours (maybe I used the wrong keywords?)

Second question: should this be reported directly to Apple?

Third question: Even if this is a bug, would it make sense to implement a patch in python that raises some exception if st_ino is zero when opening a file? Or am I simplifying too much and in some conditions st_ino=0 is valid on some types of mounted filesystems? Is there some other way to have a more atomic behaviour for this race condition in python?

Thanks a lot!

----------
components: IO, macOS
files: concurrency-tests.tar.gz
messages: 373606
nosy: Giovanni Pizzi, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Race conditions when opening and deleting a file on Mac OS X
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49315/concurrency-tests.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41291>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:22:12 2020
From: report at bugs.python.org (Rishi)
Date: Mon, 13 Jul 2020 14:22:12 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1594650132.89.0.208384642928.issue41045@roundup.psfhosted.org>


Rishi <rishi93dev at gmail.com> added the comment:

Hello all,

Could I help by adding this to the documentation ?

----------
nosy: +rishi93

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:23:32 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Jul 2020 14:23:32 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1594650212.03.0.395056213968.issue41045@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

@rishi93: yes, please do!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:38:16 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 13 Jul 2020 14:38:16 +0000
Subject: [issue37237] python 2.16 from source on Ubuntu 18.04
In-Reply-To: <1560273641.16.0.656737490919.issue37237@roundup.psfhosted.org>
Message-ID: <1594651096.74.0.16682770447.issue37237@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2.7 is no longer supported, so I think this issue should be closed.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37237>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:49:36 2020
From: report at bugs.python.org (Michel Samia)
Date: Mon, 13 Jul 2020 14:49:36 +0000
Subject: [issue41292] Dead link in Windows FAQ
Message-ID: <1594651776.92.0.628399384515.issue41292@roundup.psfhosted.org>


New submission from Michel Samia <stardust1985 at gmail.com>:

In https://github.com/python/cpython/blob/master/Doc/faq/windows.rst, the link "https://anthony-tuininga.github.io/cx_Freeze/" is dead. The new valid URL is probably https://cx-freeze.readthedocs.io/en/latest/

----------
assignee: docs at python
components: Documentation
messages: 373610
nosy: Michel Samia, docs at python
priority: normal
severity: normal
status: open
title: Dead link in Windows FAQ
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/issue41292>
_______________________________________

From report at bugs.python.org  Mon Jul 13 11:00:43 2020
From: report at bugs.python.org (Michel Samia)
Date: Mon, 13 Jul 2020 15:00:43 +0000
Subject: [issue41292] Dead link in Windows FAQ
In-Reply-To: <1594651776.92.0.628399384515.issue41292@roundup.psfhosted.org>
Message-ID: <1594652443.77.0.779519151076.issue41292@roundup.psfhosted.org>


Change by Michel Samia <stardust1985 at gmail.com>:


----------
keywords: +patch
pull_requests: +20610
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21463

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41292>
_______________________________________

From report at bugs.python.org  Mon Jul 13 11:25:54 2020
From: report at bugs.python.org (Rajarishi Devarajan)
Date: Mon, 13 Jul 2020 15:25:54 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1594653954.16.0.431916791232.issue41045@roundup.psfhosted.org>


Change by Rajarishi Devarajan <rishi93dev at gmail.com>:


----------
keywords: +patch
pull_requests: +20612
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 13 11:27:56 2020
From: report at bugs.python.org (Rajarishi Devarajan)
Date: Mon, 13 Jul 2020 15:27:56 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1594654076.92.0.154422856111.issue41045@roundup.psfhosted.org>


Rajarishi Devarajan <rishi93dev at gmail.com> added the comment:

Thank you very much. I have made a pull request. Looking forward to your review on my first open-source contribution :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 13 11:59:50 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 13 Jul 2020 15:59:50 +0000
Subject: [issue37237] python 2.16 from source on Ubuntu 18.04
In-Reply-To: <1560273641.16.0.656737490919.issue37237@roundup.psfhosted.org>
Message-ID: <1594655990.14.0.214609498413.issue37237@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37237>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:43:11 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 13 Jul 2020 16:43:11 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594658591.16.0.955842691649.issue41282@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

It's too late to add a new deprecation in the Python 3.9 cycle. Next week is the *last* beta release. Most beta testing already took place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:50:52 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 13 Jul 2020 16:50:52 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594659052.95.0.30203852739.issue41282@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> So what is the plan to continue to support building cpython itself which depends on Distutils? Currently the build bootstraps itself without the aid of an existing Python interpreter instance. There would also be major impacts across the whole cpython development process.

My understanding was that the plan was to move the standard library distutils into a private module somewhere in the standard library and presumably to slim it down to only the bare minimum required for what is necessary to build Python itself. We're really only concerned with the use of distutils to build packages.

> For example, there are many open Distutils issues in the bugs.python.org bug tracker. We need a plan on how those are to be handled (and that should take into account the expected transition from b.p.o to GitHub issues).  People will continue to submit issues agains Distutils there so triage team members and core developers need to know how to handle such issues. What if an issue applies also or only to a previous release branch (i.e. where Distutils is still in the repo)?

As far as I can tell we've already been telling people that issues in distutils should be fixed in setuptools instead for a few years. I don't think anything needs to be done about the currently open distutils tickets before we *deprecate* distutils, though during the deprecation period we'll probably want to decide whether we want to migrate them, do a mass closure or just leave them to be ad hoc closed as people stumble upon them later. Mass closure may be complicated because tickets affecting CPython itself will still need to be addressed.

> What about Distutils documentation in the Python docset?  THose are just some off the top of my head.

The distutils documentation is already basically just a warning page that says "stop using distutils": https://docs.python.org/3/library/distutils.html#module-distutils

Before these reference materials are removed from the docs we'll need to make sure that all the stuff that's still supported is documented on the setuptools side.

> I don't think any of these issues are necessarily blockers but they need to be planned for and reviewed.  I think a PEP is definitely in order for a change of this magnitude.

A PEP may be a good idea, but I do think the change doesn't have a particularly large magnitude. Anyone using setuptools or pip has already been getting setuptools' monkey-patched version of distutils for ages now, and soon they will be getting setuptools' vendored version. The documentation already indicates that distutils is at least soft-deprecated in favor of setuptools and we've already been directing issues and PRs to setuptools instead of distutils. This last piece is really formalizing something we've been incrementally working towards for a long time now. Doesn't mean we shouldn't do it carefully and with a lot of notice, but it's also not a sudden and massive shift.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:52:31 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Jul 2020 16:52:31 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594659151.63.0.834860108175.issue41282@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Deprecating in 3.10 is fine - everyone who needs to know about it releases whenever they like anyway, so we just need to make _some_ announcement.

I'd propose either moving it to Tools/distutils, or renaming it to _distutils. The point is that we're saying it's only fit for use for the core build now, and nobody else should ever import it (or complain about it ;) ).

----------
nosy:  -p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:54:44 2020
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 13 Jul 2020 16:54:44 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594659284.72.0.717943203921.issue41282@roundup.psfhosted.org>


Donald Stufft <donald at stufft.io> added the comment:

Maybe it would make sense to remove distutils from the name completely, _buildutils or something. Dunno, seems like it might be reasonable just to further separate it from the concept of "distutils" the public library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 13:43:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jul 2020 17:43:52 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594662232.03.0.248250756316.issue41282@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 14:17:09 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jul 2020 18:17:09 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594664229.4.0.36689867761.issue41288@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 620e276a8c1d53332fbf08d369be87f862b6949d by Miss Islington (bot) in branch '3.7':
bpo-41288: Fix a crash in unpickling invalid NEWOBJ_EX. (GH-21458) (GH-21461)
https://github.com/python/cpython/commit/620e276a8c1d53332fbf08d369be87f862b6949d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 14:18:11 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jul 2020 18:18:11 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594664291.01.0.789415825279.issue41288@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 6463cf07fef7a923a743fcaf312150c45fd81b64 by Miss Islington (bot) in branch '3.6':
bpo-41288: Fix a crash in unpickling invalid NEWOBJ_EX. (GH-21458) (GH-21462)
https://github.com/python/cpython/commit/6463cf07fef7a923a743fcaf312150c45fd81b64


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 14:19:55 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jul 2020 18:19:55 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594664395.4.0.0604255732209.issue41288@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 13 14:20:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Jul 2020 18:20:13 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594664413.86.0.720512814923.issue29778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Correction: the original discovery credit goes to Eran Shimony <Eran.Shimony at cyberark.com> and Ido Hoorvitch  <Ido.Hoorvitch at cyberark.com> from CyberArk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul 13 15:41:31 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 13 Jul 2020 19:41:31 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1594669291.41.0.935356210116.issue40219@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
pull_requests: +20613
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21467

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Mon Jul 13 15:46:18 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 13 Jul 2020 19:46:18 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1594669578.82.0.919114905814.issue40219@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Mon Jul 13 16:26:50 2020
From: report at bugs.python.org (Pavel Trukhanov)
Date: Mon, 13 Jul 2020 20:26:50 +0000
Subject: [issue41293] fix confusing example in hashlib docs
Message-ID: <1594672010.58.0.839432407468.issue41293@roundup.psfhosted.org>


New submission from Pavel Trukhanov <pavel.trukhanov at gmail.com>:

The documentation found in https://docs.python.org/3/library/hashlib.html#hash-algorithms

give us the following two examples:

```
For example, to obtain the digest of the byte string b'Nobody inspects the spammish repetition':

>>>
>>> import hashlib
>>> m = hashlib.sha256()
>>> m.update(b"Nobody inspects")
>>> m.update(b" the spammish repetition")
>>> m.digest()
b'\x03\x1e\xdd}Ae\x15\x93\xc5\xfe\\\x00o\xa5u+7\xfd\xdf\xf7\xbcN\x84:\xa6\xaf\x0c\x95\x0fK\x94\x06'
>>> m.digest_size
32
>>> m.block_size
64

More condensed:
>>>
hashlib.sha224(b"Nobody inspects the spammish repetition").hexdigest()
'a4337bc45a8fc544c03f52dc550cd6e1e87021bc896588bd79e901e2'
hashlib
```
It's confusing because two examples use different algo - sha256 and sha224, respectfully. 

Also the first one gets `.digest()` while the other - `.hexdigest()`, which are incomparable.

----------
assignee: docs at python
components: Documentation
messages: 373619
nosy: Pavel Trukhanov, docs at python
priority: normal
severity: normal
status: open
title: fix confusing example in hashlib docs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41293>
_______________________________________

From report at bugs.python.org  Mon Jul 13 16:28:16 2020
From: report at bugs.python.org (Pavel Trukhanov)
Date: Mon, 13 Jul 2020 20:28:16 +0000
Subject: [issue41293] fix confusing example in hashlib docs
In-Reply-To: <1594672010.58.0.839432407468.issue41293@roundup.psfhosted.org>
Message-ID: <1594672096.4.0.52542955802.issue41293@roundup.psfhosted.org>


Change by Pavel Trukhanov <pavel.trukhanov at gmail.com>:


----------
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/issue41293>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:31:14 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 13 Jul 2020 21:31:14 +0000
Subject: [issue32192] Provide importlib.util.lazy_import helper function
In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za>
Message-ID: <1594675874.52.0.0612862226934.issue32192@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 8dd32fe645c9503cf8e6be4b1580c3a59b450168 by Joannah Nanjekye in branch 'master':
bpo-32192: A basic lazy importer example (GH-21330)
https://github.com/python/cpython/commit/8dd32fe645c9503cf8e6be4b1580c3a59b450168


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32192>
_______________________________________

From report at bugs.python.org  Mon Jul 13 19:30:12 2020
From: report at bugs.python.org (William Pickard)
Date: Mon, 13 Jul 2020 23:30:12 +0000
Subject: [issue41294] Allow '__qualname__' to be an instance of
 'DynamicClassAttribute'
Message-ID: <1594683012.02.0.626450993111.issue41294@roundup.psfhosted.org>


New submission from William Pickard <lollol222gg at gmail.com>:

Currently within Python, the attribute '__qualname__' is restricted to only be a string valued attribute.

This makes is rather cumbersome for anyone who wants to implement '__qualname__' as a property, instead of a plain attribute (especially if '__slots__' are used)

Python also has the type 'DynamicClassAttribute' who's only first party user is the 'enum' module, BUT it only supports shadow get requests.

Therefore, I'm requesting both changing DynamicClassAttribute to supoort __set__ and __del__ to function like __get__ AND to allow __qualname__ to be an instance of DynamicClassAttribute.

----------
messages: 373621
nosy: WildCard65
priority: normal
severity: normal
status: open
title: Allow '__qualname__' to be an instance of 'DynamicClassAttribute'
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41294>
_______________________________________

From report at bugs.python.org  Mon Jul 13 20:15:28 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Jul 2020 00:15:28 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594685728.16.0.876555031603.issue41282@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

FYI PEP 387 (which I expect will be accepted once I catch up from vacation) specified deprecations are to be public for two releases before removal or approval from the SC for a shorter cycle.

So if distutils is deprecated in 3.10 then it can be removed in 3.12 or you can ask the SC for an exemption to do it in 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Mon Jul 13 21:40:46 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 14 Jul 2020 01:40:46 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1594690846.6.0.815047071817.issue41045@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 13 21:43:36 2020
From: report at bugs.python.org (ramalho)
Date: Tue, 14 Jul 2020 01:43:36 +0000
Subject: [issue40978] Document that typing.SupportsXXX protocols are runtime
 checkable
In-Reply-To: <1592163787.83.0.523481527574.issue40978@roundup.psfhosted.org>
Message-ID: <1594691016.12.0.30478584061.issue40978@roundup.psfhosted.org>


ramalho <luciano at ramalho.org> added the comment:

After experimenting with theses protocols, I believe the user community is better served by leaving undocumented the fact that they are runtime checkable, because their runtime results are inconsistent with how Mypy handles them, producing both false positives and false negatives.

I've documented the problems (https://github.com/fluentpython/abc-protocol-labs/blob/master/protocol-issues.rst) and started two threads about them in the typing-sig mailing list:

[1] https://mail.python.org/archives/list/typing-sig at python.org/message/CSM3ZCWNRBO4RGGTSM664DD37JYOUVCO/ 
[2] https://mail.python.org/archives/list/typing-sig at python.org/message/FSV6WSFGWD4QZO6ECY3JADF7M2PW5FKK/

Thread [1] got a useful partial response from Guido. Open questions remain. Thread [2] got no response at all.

I will gladly reengage in those threads or in this issue if there is interest. As it stands, I believe the use of the @runtime_checkable feature on several of these protocols is unreliable and should not be promoted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40978>
_______________________________________

From report at bugs.python.org  Tue Jul 14 00:07:26 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Jul 2020 04:07:26 +0000
Subject: [issue41293] fix confusing example in hashlib docs
In-Reply-To: <1594672010.58.0.839432407468.issue41293@roundup.psfhosted.org>
Message-ID: <1594699646.36.0.062115182814.issue41293@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +christian.heimes, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41293>
_______________________________________

From report at bugs.python.org  Tue Jul 14 01:31:33 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Jul 2020 05:31:33 +0000
Subject: [issue41287] __doc__ attribute is not set in property-derived classes
In-Reply-To: <1594586083.6.0.902653661287.issue41287@roundup.psfhosted.org>
Message-ID: <1594704693.78.0.743528823707.issue41287@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What would you expect this to print?

class Property(property):
    'custom docstring'

print(Property(None, None, None, "hello").__doc__)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41287>
_______________________________________

From report at bugs.python.org  Tue Jul 14 01:49:48 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 14 Jul 2020 05:49:48 +0000
Subject: [issue32695] tarfile.open() raises TypeError when using compresslevel
 parameter with LZMA
In-Reply-To: <1517152925.99.0.467229070634.issue32695@psf.upfronthosting.co.za>
Message-ID: <1594705788.67.0.676389479852.issue32695@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 1.0 -> 2.0
pull_requests: +20614
pull_request: https://github.com/python/cpython/pull/21470

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32695>
_______________________________________

From report at bugs.python.org  Tue Jul 14 02:48:31 2020
From: report at bugs.python.org (Alex)
Date: Tue, 14 Jul 2020 06:48:31 +0000
Subject: [issue41278] Wrong Completion on Editing Mode of IDLE
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594709311.03.0.489036783732.issue41278@roundup.psfhosted.org>


Alex <2423067593 at qq.com> added the comment:

Well. I found that this bug happens frequntly, sometimes it just shows the proper list, like __builtins__, __docs__ and stuff. Sometimes the completion windows just gives me 'idlelib'.
p.s.:idle won't show __main__ when you type something and press ctrl+space, but the completion *seems do* exist (and gives the proper list that I said before) when you type ctrl+space, but by pressing enter a NameError is raised because __main__ *do not* exist, actually. I'm finding out why this happens, and when.
p.p.s:I'm using python 3.8.2 shell.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Tue Jul 14 02:50:43 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Jul 2020 06:50:43 +0000
Subject: [issue41293] fix confusing example in hashlib docs
In-Reply-To: <1594672010.58.0.839432407468.issue41293@roundup.psfhosted.org>
Message-ID: <1594709443.8.0.040339657216.issue41293@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I probably I wrote these docs (a long time ago).  The examples are being used to demonstrate different uses of the APIs including calling update multiple times, different algorithms, a binary digest and a hex digest.  

They weren't mean to show equivalence, but I agree... the wording could be improved to make what they are doing and why more clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41293>
_______________________________________

From report at bugs.python.org  Tue Jul 14 03:16:29 2020
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 14 Jul 2020 07:16:29 +0000
Subject: [issue41122] functools.singledispatchfunction has confusing error
 message if no positional arguments are passed in
In-Reply-To: <1593142171.21.0.765046839926.issue41122@roundup.psfhosted.org>
Message-ID: <1594710989.32.0.265536320274.issue41122@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +20615
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21471

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41122>
_______________________________________

From report at bugs.python.org  Tue Jul 14 03:19:25 2020
From: report at bugs.python.org (Sergei Izmailov)
Date: Tue, 14 Jul 2020 07:19:25 +0000
Subject: [issue41287] __doc__ attribute is not set in property-derived classes
In-Reply-To: <1594586083.6.0.902653661287.issue41287@roundup.psfhosted.org>
Message-ID: <1594711165.92.0.234153488351.issue41287@roundup.psfhosted.org>


Sergei Izmailov <sergei.a.izmailov at gmail.com> added the comment:

class Property(property):
    'custom docstring'

print(Property(None, None, None, "hello").__doc__)

This snippet is expected to print "hello" as well (at least it's what comment in cpython implementation suggests) 

https://github.com/python/cpython/blob/master/Objects/descrobject.c#L1712-L1715

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41287>
_______________________________________

From report at bugs.python.org  Tue Jul 14 04:10:25 2020
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 14 Jul 2020 08:10:25 +0000
Subject: [issue41275] Clarify whether Futures can be awaited multiple times
In-Reply-To: <1594435318.81.0.780838422603.issue41275@roundup.psfhosted.org>
Message-ID: <1594714225.62.0.0114396435648.issue41275@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41275>
_______________________________________

From report at bugs.python.org  Tue Jul 14 04:40:07 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 14 Jul 2020 08:40:07 +0000
Subject: [issue41275] Clarify whether Futures can be awaited multiple times
In-Reply-To: <1594435318.81.0.780838422603.issue41275@roundup.psfhosted.org>
Message-ID: <1594716007.73.0.539749235752.issue41275@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The allowance to wait for the future object multiple times is settled in stone. This cannot be changed without breaking very many codes.

So yes, asyncio guarantees that the feature is settled in stone. If set_value() / set_exception() was called, the value/exception is returned (raised) on every following `await fut`.


Pull request for documentation with clarification of the status quo is welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41275>
_______________________________________

From report at bugs.python.org  Tue Jul 14 04:48:03 2020
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 14 Jul 2020 08:48:03 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594716483.25.0.833966284196.issue41282@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

> It's too late to add a new deprecation in the Python 3.9 cycle

Please can we add a note in 3.9, that it will be deprecated in 3.10?

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 04:59:47 2020
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 14 Jul 2020 08:59:47 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594717187.85.0.318622639061.issue41282@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

Renaming distutils to _buildutils only delays the problem to remove it.  But yes, it explicitly makes it explicit that code needs to be changed.

I would like to see that neither distutils or _buildutils is installed by default, and only is available internally for building the extensions of CPython.

The "old" build system to build builtins instead of extensions is still functional, so it should be ok to build the extensions also with the old build system.

That would require moving all the config stuff in setup.py to autoconf tests, which is perfectly doable.  The MacOS and Windows builds would need some attention too, but afaicr when asking Ned Deily and Steve Dower at the language summits, they didn't have a concern about this approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 05:15:58 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Jul 2020 09:15:58 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594718158.14.0.383815622241.issue41282@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

+1

I would like to propose three changes:

1) rename distutils, either _distutils or _buildutils sounds good to me
2) make distutils a build-only dependency and no longer install it with make install and other install targets
3) start to build extensions from Makefile or Modules/Setup

For (3) we have to move some checks into autoconf and maybe extend Modules/Setup to support conditional compilation.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 05:29:26 2020
From: report at bugs.python.org (jvoisin)
Date: Tue, 14 Jul 2020 09:29:26 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594718966.92.0.70751796716.issue39017@roundup.psfhosted.org>


jvoisin <jvoisin at google.com> added the comment:

CVE-2019-20907 has been assigned to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Tue Jul 14 05:39:02 2020
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 14 Jul 2020 09:39:02 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594719542.34.0.71010976477.issue41282@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

> A PEP may be a good idea, but I do think the change doesn't have a
> particularly large magnitude. Anyone using setuptools or pip has
> already been getting setuptools' monkey-patched version of distutils
> for ages now, and soon they will be getting setuptools' vendored
> version. The documentation already indicates that distutils is at
> least soft-deprecated in favor of setuptools and we've already been
> directing issues and PRs to setuptools instead of distutils.

I don't think it's a good idea to replace bad habits from distutils with bad habits in setuptools._distutils.  And this is exactly what you get with pointing directly to setuptools.

While splitting out distutils to a separate package in a Linux distro, I found some creative usages at runtime of a package (see my lightning talk at the language summit 2018, and [1]).  From my point of view, CPython should provide documentation how to forward-port these issues without using setuptools._distutils.

Currently setuptools only has one component (pkg_resources, [2]) which is used at runtime.  I dislike it if more than that is used at runtime of a package.

[1] https://mail.python.org/archives/list/distutils-sig at python.org/thread/74WZ7D3ARF7B3N6MAV2JBV3DW6TRHFIV/
[2] https://github.com/pypa/setuptools/issues/863

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 06:14:16 2020
From: report at bugs.python.org (Ma Lin)
Date: Tue, 14 Jul 2020 10:14:16 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1594721656.93.0.777780908386.issue37095@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

> Add zstd support in tarfile

This requires the stdlib to contain a Zstandard module.

You can ask in the Idea forum:
https://discuss.python.org/c/ideas

----------
nosy: +malin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Tue Jul 14 06:57:31 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 14 Jul 2020 10:57:31 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594724251.69.0.540221243387.issue41282@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 08:07:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Jul 2020 12:07:48 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1594728468.22.0.877886258343.issue41288@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +20616
pull_request: https://github.com/python/cpython/pull/21472

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Tue Jul 14 09:32:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 14 Jul 2020 13:32:33 +0000
Subject: [issue41278] Wrong Completion on Editing Mode of IDLE
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594733553.1.0.657296694528.issue41278@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We cannot do anything with this report unless you give exact keystroke-by-keystroke details and we are able to reproduce the issue.  Also, what OS?  If *nix, which?  How did you start IDLE?

Unless you start IDLE with -n or explicitly import idlelib, it should not be possible for idlelib to appear as a completion.  The run.py code was written to avoid adding anything to the main namespace.  When you start or restart Shell, dir() only lists double underscore names.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Tue Jul 14 09:46:22 2020
From: report at bugs.python.org (Abhijeet Kasurde)
Date: Tue, 14 Jul 2020 13:46:22 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1594734382.25.0.995807307552.issue41182@roundup.psfhosted.org>


Abhijeet Kasurde <akasurde at redhat.com> added the comment:

Any news?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Tue Jul 14 10:57:16 2020
From: report at bugs.python.org (kam193)
Date: Tue, 14 Jul 2020 14:57:16 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
Message-ID: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>


New submission from kam193 <kam193 at wp.pl>:

CPython 3.8.4 broke previously correct custom __setattr__ implementation, when metaclass inheritances from multiple classes, including not-meta.

Following code:

```
class Meta(type):
    def __setattr__(cls, key, value):
        type.__setattr__(cls, key, value)

class OtherClass:
    pass


class DefaultMeta(OtherClass, Meta):
    pass

obj = DefaultMeta('A', (object,), {})
obj.test = True
print(obj.test)
```

Works in Python up to 3.8.3, but in 3.8.4 it raises:

Traceback (most recent call last):
  File "repr.py", line 13, in <module>
    obj.test = True
  File "repr.py", line 3, in __setattr__
    type.__setattr__(cls, key, value)
TypeError: can't apply this __setattr__ to DefaultMeta object

This change affects e.g. https://github.com/pallets/flask-sqlalchemy/issues/852

----------
messages: 373637
nosy: kam193
priority: normal
severity: normal
status: open
title: CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:02:31 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 14 Jul 2020 15:02:31 +0000
Subject: [issue41278] Wrong Completion on Editing Mode of IDLE
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594738951.8.0.390733656979.issue41278@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I can only seem to reproduce this in shell and that is by importing "idlelib.__main__" before then typing "__main__."

However, typing "__main__." in shell and editor (without importing "idlelib.__main__") does give different completions. In shell, it gives a list of the usual "__annotations__", "__builtins__", etc. However, in editor (run from the home directory without any command-line flags), the only completion is "main" (note: the shell must be closed, otherwise it will give the same completions as the shell)

----------
nosy: +epaine

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:13:45 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Jul 2020 15:13:45 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594739625.18.0.843023309635.issue41286@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think your best bet will be to write a small C extension to find out what's supported by the processor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:13:49 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Jul 2020 15:13:49 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594739629.51.0.0908761120994.issue41295@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +3.8regression
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:17:19 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Jul 2020 15:17:19 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594739839.58.0.324424873165.issue41295@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The error message is coming from hackcheck function in Objects/typeobject.c, https://github.com/python/cpython/blob/b4cd77de05e5bbaa6a4be90f710b787e0790c36f/Objects/typeobject.c#L5811-L5845 . The issue could be related to bpo-39960. Checking now...

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:23:17 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Jul 2020 15:23:17 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594740197.43.0.995605041504.issue41295@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The regression was introduced in commit 8912c182455de83e27d5c120639ec91b18247913

$ git checkout v3.8.4
$ ./configure -C
$ make
$ $ ./python bpo41295.py 
Traceback (most recent call last):
  File "bpo41295.py", line 14, in <module>
    obj.test = True
  File "bpo41295.py", line 3, in __setattr__
    type.__setattr__(cls, key, value)
TypeError: can't apply this __setattr__ to DefaultMeta object

$ git revert 8912c182455de83e27d5c120639ec91b18247913
[detached HEAD 8d3c7847a0] Revert "bpo-39960: Allow heap types in the "Carlo Verre" hack check that override "tp_setattro()" (GH-21092) (GH-21339)"
 3 files changed, 11 insertions(+), 117 deletions(-)
$ make
$ ./python bpo41295.py 
True

----------
keywords: +3.9regression
priority: normal -> release blocker
versions: +Python 3.10, Python 3.9
Added file: https://bugs.python.org/file49316/bpo41295.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:23:55 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Jul 2020 15:23:55 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594740235.69.0.583253658366.issue41295@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Stefan, please take a look.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:36:22 2020
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 14 Jul 2020 15:36:22 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594740982.39.0.206055817491.issue41286@roundup.psfhosted.org>


Bo?tjan Mejak <bostjan.xperia at gmail.com> added the comment:

Unfortunately, I don't know C, only Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:41:44 2020
From: report at bugs.python.org (David Lord)
Date: Tue, 14 Jul 2020 15:41:44 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594741304.35.0.429582591639.issue41295@roundup.psfhosted.org>


David Lord <davidism at gmail.com> added the comment:

It appears to be solved in Flask-SQLAlchemy's development version already, as the mixins now inherit from `type`. We caught the issue when we started applying flake8 (possibly through flake8-bugbear).

----------
nosy: +davidism

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 11:43:32 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Tue, 14 Jul 2020 15:43:32 +0000
Subject: [issue35247] test.test_socket.RDSTest.testPeek hangs indefinitely
In-Reply-To: <1542212087.25.0.788709270274.issue35247@psf.upfronthosting.co.za>
Message-ID: <1594741412.39.0.0324374204971.issue35247@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

I can reproduce test_socket hanging in 2 out of 3 runs. However, in my case testPeek doesn't seem to be the (only) culprit.  Disabling whole RDSTest helps.

----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35247>
_______________________________________

From report at bugs.python.org  Tue Jul 14 12:29:23 2020
From: report at bugs.python.org (David Caro)
Date: Tue, 14 Jul 2020 16:29:23 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1594744163.4.0.581583971139.issue39960@roundup.psfhosted.org>


Change by David Caro <david at dcaro.es>:


----------
nosy: +David Caro
nosy_count: 5.0 -> 6.0
pull_requests: +20618
pull_request: https://github.com/python/cpython/pull/21473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39960>
_______________________________________

From report at bugs.python.org  Tue Jul 14 12:29:23 2020
From: report at bugs.python.org (David Caro)
Date: Tue, 14 Jul 2020 16:29:23 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594744163.28.0.559433062539.issue41295@roundup.psfhosted.org>


Change by David Caro <david at dcaro.es>:


----------
keywords: +patch
nosy: +David Caro
nosy_count: 5.0 -> 6.0
pull_requests: +20617
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 12:32:27 2020
From: report at bugs.python.org (David Caro)
Date: Tue, 14 Jul 2020 16:32:27 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594744347.17.0.544389939963.issue41295@roundup.psfhosted.org>


David Caro <david at dcaro.es> added the comment:

Just sent a PR that fixes the issue (a first approach), let me know if it's addressing the issue correctly or if there's a better way.


Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Tue Jul 14 12:49:22 2020
From: report at bugs.python.org (JustAnotherArchivist)
Date: Tue, 14 Jul 2020 16:49:22 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1594745362.09.0.00309697414209.issue32528@roundup.psfhosted.org>


Change by JustAnotherArchivist <justanotherarchivist at riseup.net>:


----------
pull_requests: +20619
pull_request: https://github.com/python/cpython/pull/21474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:05:16 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 14 Jul 2020 17:05:16 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1594746316.33.0.844901787202.issue39960@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Reopening because there appears to be a problem with the fix (see PR 21473).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39960>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:06:26 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 14 Jul 2020 17:06:26 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1594746386.21.0.420642110757.issue39960@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Stefan Do you agree that the fix proposed in PR 21473 needs to be made?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39960>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:08:30 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Jul 2020 17:08:30 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594746510.22.0.744263388663.issue41282@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The Windows build doesn't depend on distutils at all. We've had dedicated build scripts for each module since before I started contributing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:22:51 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Jul 2020 17:22:51 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1594747371.03.0.918542473925.issue32528@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2a5181829af394b82e8e8c917183c709ee72a2b7 by JustAnotherArchivist in branch 'master':
bpo-32528: Document the change in inheritance of asyncio.CancelledError (GH-21474)
https://github.com/python/cpython/commit/2a5181829af394b82e8e8c917183c709ee72a2b7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:22:58 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Jul 2020 17:22:58 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1594747378.29.0.197107222144.issue32528@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20620
pull_request: https://github.com/python/cpython/pull/21475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:23:05 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Jul 2020 17:23:05 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1594747385.71.0.236672100075.issue32528@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20621
pull_request: https://github.com/python/cpython/pull/21476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Tue Jul 14 13:28:49 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Jul 2020 17:28:49 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594747729.34.0.0417753547328.issue41282@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The Windows build system didn't use setu.py even before I upgrade the VS build system to VS 2010.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 14:03:33 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 14 Jul 2020 18:03:33 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594749813.94.0.182394980805.issue41282@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> I don't think it's a good idea to replace bad habits from distutils with bad habits in setuptools._distutils.  And this is exactly what you get with pointing directly to setuptools.

These are two different questions. We're not asking people to migrate to `setuptools._distutils` (a private module which may not continue to exist in that location), `setuptools` is *adopting* `distutils`, such that `distutils` is a project provided by `pip install distutils` (mind you, this is happening independent of what the standard library does ? the only question is whether `import distutils` continues to work if you don't have `setuptools` installed).

> While splitting out distutils to a separate package in a Linux distro, I found some creative usages at runtime of a package (see my lightning talk at the language summit 2018, and [1]).  From my point of view, CPython should provide documentation how to forward-port these issues without using setuptools._distutils.

At this point, the extent of CPython's documentation on this should probably be, "We are removing `distutils` and moving it into the `setuptools` namespace. In future versions, you will need to install `setuptools` to import the `distutils` package." `setuptools` should almost certainly deprecate `distutils` and probably remove large swathes of it in the process, but that's probably on a case-by-case basis, and it's a separate issue from what needs to happen in CPython.

> Currently setuptools only has one component (pkg_resources, [2]) which is used at runtime.  I dislike it if more than that is used at runtime of a package.

I don't think anyone is planning to recommend the use of *any* `setuptools`-provided packages at runtime, including `pkg_resources`. This move is actually a good one from that point of view, because it will require that projects using `distutils` declare a *runtime* dependency on `setuptools`, which will, hopefully, raise some eyebrows. Better than the current situation, where these dependencies are totally undeclared (though probably worse than if `setuptools`, `pkg_resources` and `distutils` were all separate PyPI packages).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 14:54:46 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 14 Jul 2020 18:54:46 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1594752886.53.0.998971204777.issue41282@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Oops, just realized my previous post said `pip install distutils`. I meant to say that `pip install setuptools` will provide the `distutils` module (right now you do `import setuptools; import distutils` and you get the setuptools-provided version; we're working on a version where `import distutils` comes from `setuptools` regardless of the import order).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Tue Jul 14 15:03:59 2020
From: report at bugs.python.org (john passaro)
Date: Tue, 14 Jul 2020 19:03:59 +0000
Subject: [issue41296] unittest.mock: patched mocks do not propagate calls to
 parent when set via setattr
Message-ID: <1594753439.43.0.455060750875.issue41296@roundup.psfhosted.org>


New submission from john passaro <john.a.passaro at gmail.com>:

I expected the following code to print True:

<pre>
import os
from unittest.mock import call, Mock, patch

parent = Mock()
parent.getenv = patch('os.getenv')
with parent.getenv:
    os.getenv('FOO', 'bar')
expected = [call.getenv('FOO', 'bar')]
print(expected, '==', parent.mock_calls, ':', expected == parent.mock_calls)
</pre>

It works fine if you replace the statement `parent.getenv = patch('os.getenv')` with:
<pre>
parent.getenv = patch('os.getenv', _mock_parent=parent,
                      _mock_new_parent=parent, _mock_new_name='getenv')
</pre>


Background:

I was trying to make assertions about a mocked call within a mocked context generator.

<pre>
# c.py
from . import a
from . import b
def func():
    with a.context('c'):
        b.operation()
</pre>
<pre>
# test_c.py
from package.c import func
from unittest.mock import Mock, call, patch
parent = Mock()
parent.context = patch('package.a.context')
parent.operation = patch('package.b.operation')
with parent.context, parent.operation:
    func()
assert parent.mock_calls == [
   call.context('c'),
   call.context().__enter__(),
   call.operation(),
   call.context().__exit__(None, None, None),
]
</pre>

in other words, to ensure the correct order of the __enter__/__exit__ calls relative to the actual operation. I have my workaround but it's very awkward looking.

----------
components: Library (Lib)
messages: 373654
nosy: thinkingmachin6
priority: normal
severity: normal
status: open
title: unittest.mock: patched mocks do not propagate calls to parent when set via setattr
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41296>
_______________________________________

From report at bugs.python.org  Tue Jul 14 15:07:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Jul 2020 19:07:39 +0000
Subject: [issue41296] unittest.mock: patched mocks do not propagate calls to
 parent when set via setattr
In-Reply-To: <1594753439.43.0.455060750875.issue41296@roundup.psfhosted.org>
Message-ID: <1594753659.01.0.819645004057.issue41296@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41296>
_______________________________________

From report at bugs.python.org  Tue Jul 14 15:41:39 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 14 Jul 2020 19:41:39 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1594755699.01.0.153081811619.issue41273@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 568fb0ff4aa641329261cdde20795b0aa9278175 by Tony Solomonik in branch 'master':
bpo-41273: asyncio's proactor read transport's better performance by using recv_into instead of recv (#21442)
https://github.com/python/cpython/commit/568fb0ff4aa641329261cdde20795b0aa9278175


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Tue Jul 14 15:47:08 2020
From: report at bugs.python.org (thinkingmachin6)
Date: Tue, 14 Jul 2020 19:47:08 +0000
Subject: [issue41296] unittest.mock: patched mocks do not propagate calls to
 parent when set via setattr
In-Reply-To: <1594753439.43.0.455060750875.issue41296@roundup.psfhosted.org>
Message-ID: <1594756028.72.0.237114463957.issue41296@roundup.psfhosted.org>


thinkingmachin6 <john.a.passaro at gmail.com> added the comment:

This appears to be a case of RTFM (https://docs.python.org/3/library/unittest.mock.html#attaching-mocks-as-attributes). For anybody that comes across this, the short answer is use `attach_mock()` instead of plain attribute-setting.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41296>
_______________________________________

From report at bugs.python.org  Tue Jul 14 17:06:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 14 Jul 2020 21:06:13 +0000
Subject: [issue40734] /usr/bin surprisingly in sys.path under IDLE
In-Reply-To: <1590179721.27.0.0407406629035.issue40734@roundup.psfhosted.org>
Message-ID: <1594760773.55.0.538755816042.issue40734@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Lib/idlelib contains a startup file 'idle.py' (and 'idle.bat' and 'idle.pyw' on Windows).  IDLE, and I, have no control over the installation of IDLE, including the addition of system-specific auxiliary startup files and entries, with names containing 'idle', outside of /idlelib.  On Windows, there is no addition in pythondir/Scripts.  The 'IDLE' Start menu shortcut run idlelib/idle.pyw.

I believe IDLE's only manipulation of sys.path for the user process is to prepend '' or the the edited file's directory.  In my message above describing a possible experiment, 'sys.python' should be sys.path.  You can keep exploring if you want, but I am closing this for now.

----------
resolution: works for me -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40734>
_______________________________________

From report at bugs.python.org  Tue Jul 14 17:49:24 2020
From: report at bugs.python.org (alex c)
Date: Tue, 14 Jul 2020 21:49:24 +0000
Subject: [issue41297] Remove doctest import from heapq
Message-ID: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>


New submission from alex c <alexchandel at gmail.com>:

heapq.py imports doctest in the last 4 lines to perform unit tests:

    if __name__ == "__main__":
    
        import doctest # pragma: no cover
        print(doctest.testmod()) # pragma: no cover

This disrupts dependency tracking modules and software, like modulegraph and pyinstaller, as doctest brings in many dependencies (including ctypes as of 3.8).

This functionality could be factored out into a separate unit-testing file.

----------
components: Tests
messages: 373658
nosy: alexchandel
priority: normal
severity: normal
status: open
title: Remove doctest import from heapq
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/issue41297>
_______________________________________

From report at bugs.python.org  Tue Jul 14 18:02:27 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 14 Jul 2020 22:02:27 +0000
Subject: [issue41298] Enable handling logoff and shutdown Windows console
 events
Message-ID: <1594764146.97.0.760016525687.issue41298@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

A console script should be able to handle Windows console logoff and shutdown events with relatively simple ctypes code, such as the following:

    import ctypes
    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    CTRL_C_EVENT = 0
    CTRL_BREAK_EVENT = 1
    CTRL_CLOSE_EVENT = 2
    CTRL_LOGOFF_EVENT = 5
    CTRL_SHUTDOWN_EVENT = 6

    @ctypes.WINFUNCTYPE(ctypes.c_int, ctypes.c_ulong)
    def console_ctrl_handler(event):
        if event == CTRL_SHUTDOWN_EVENT:
            return handle_shutdown()
        if event == CTRL_LOGOFF_EVENT:
            return handle_logoff()
        if event == CTRL_CLOSE_EVENT:
            return handle_close()
        if event == CTRL_BREAK_EVENT:
            return handle_break()
        if event == CTRL_C_EVENT:
            return handle_cancel()
        return False # chain to next handler

    if not kernel32.SetConsoleCtrlHandler(console_ctrl_handler, True):
        raise ctypes.WinError(ctypes.get_last_error())

As of 3.9, it's not possible for python.exe to receive the above logoff and shutdown events via ctypes. In these two cases, the console doesn't even get to send a close event, so a console script cannot exit gracefully.

The session server (csrss.exe) doesn't send the logoff and shutdown console events to python.exe because it's seen as a GUI process, which is expected to handle WM_QUERYENDSESSION and WM_ENDSESSION instead. That requires creating a hidden window and running a message loop, which is not nearly as simple as a console control handler.

The system registers python.exe as a GUI process because user32.dll is loaded, which means the process is ready to interact with the desktop in every way, except for the final step of actually creating UI objects. In particular, loading user32.dll causes the system to extend the process and its threads with additional kernel data structures for use by win32k.sys (e.g. a message queue for each thread). It also opens handles for and connects to the session's "WinSta0" interactive window station (a container for an atom table, clipboard, and desktops) and "Default" desktop (a container for UI objects such as windows, menus, and hooks). (The process can connect to a different desktop or window station if set in the lpDesktop field of the process startup info. Also, if the process access token is for a service or batch logon, by default it connects to a non-interactive window station that's named for the logon ID. For example, the SYSTEM logon ID is 0x3e7, so a SYSTEM service or batch process gets connected to "Service-0x0-3e7$".)

Prior to 3.9, python3x.dll loads shlwapi.dll (the lightweight shell API) to access the Windows path functions PathCanonicalizeW and PathCombineW. shlwapi.dll in turn loads user32.dll. 3.9+ is one step closer to the non-GUI goal because it no longer depends on shlwapi.dll. Instead it always uses the newer PathCchCanonicalizeEx and PathCchCombineEx functions from api-ms-win-core-path-l1-1-0.dll, which is implemented by the base API (kernelbase.dll) instead of the shell API. 

The next hurdle is extension modules, especially the _ctypes extension module, since it's needed for the console control handler. _ctypes.pyd loads ole32.dll, which in turn loads user32.dll. This is just to call ProgIDFromCLSID, which is rarely used. I see no reason that ole32.dll can't be delay loaded or just manually link to ProgIDFromCLSID on first use via GetModuleHandleW / LoadLibraryExW and GetProcAddress. I did a quick patch to implement the latter, and, since user32.dll no longer gets loaded, the console control handler is enabled for console logoff and shutdown events. So this is the minimal fix to resolve this issue in 3.9+.

--- 
Additional modules

winsound loads user32.dll for MessageBeep. The Beep and PlaySound functions don't require user32.dll, so winsound is still useful if it gets delay loaded. 

_ssl and _hashlib depend on libcrypto, which loads user32.dll for MessageBoxW, GetProcessWindowStation and GetUserObjectInformationW. The latter two are called in OPENSSL_isservice [1] in order to get the window station name. If StandardError isn't a valid file handle, OPENSSL_isservice determines whether an error should be reported as an event or interactively shown with a message box. user32.dll can be delay loaded for this, which, if I'm reading the source right, will never occur as long as StandardError is a valid file.
 
[1]: https://github.com/openssl/openssl/blob/e7fb44e7c3f7a37ff83a6b69ba51a738e549bf5c/crypto/cryptlib.c#L193

----------
components: Extension Modules, Library (Lib), Windows, ctypes
messages: 373659
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable handling logoff and shutdown Windows console events
type: enhancement
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41298>
_______________________________________

From report at bugs.python.org  Tue Jul 14 18:15:57 2020
From: report at bugs.python.org (SD)
Date: Tue, 14 Jul 2020 22:15:57 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
Message-ID: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>


New submission from SD <scott-devine at hotmail.co.uk>:

The overhead in Python 3 for threading.Event().wait() is much larger than Python 2. I am trying to run a script at 60hz which worked correctly in Python2 but does not in Python 3. Here is a minimal example to demonstrate: 

#!/usr/bin/env python

import threading
import time

def sample_thread(stop_ev):
    while not stop_ev.is_set():
        t2 = time.time() 
        stop_ev.wait(0.016999959945)
        print((time.time() - t2))

def main():
    stop_ev = threading.Event()
    sample_t = threading.Thread(target=sample_thread, args=(stop_ev, ))
    sample_t.start()

    # Other stuff here, sleep is just dummy
    time.sleep(14)

    stop_ev.set()

    print('End reached.')

if __name__ == '__main__':
    main()

Python 2.7.0 consistently prints :

0.0169999599457
0.0169999599457
0.0170001983643
0.0169999599457
0.0169999599457
0.0169999599457
0.0169999599457
0.0169999599457

Python 3.8.2 waits much longer

0.031026363372802734
0.0320279598236084
0.031026363372802734
0.031026840209960938
0.031527042388916016
0.031026601791381836
0.03103041648864746
0.03302431106567383

----------
messages: 373660
nosy: SD
priority: normal
severity: normal
status: open
title: Python3 threading.Event().wait time is twice as large as Python27
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Tue Jul 14 18:56:08 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 14 Jul 2020 22:56:08 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1594767368.26.0.0259177105515.issue41297@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The idiom of a module running doctests on itself when executed as a script is a common idiom.

If modulegraph and pyinstaller can't cope a module importing another module from inside an if statement, that's a bug in them, not in the heapq module (and many others).

This requested change is a regression, taking away functionality. 3.8 and older are in feature freeze, so this could only apply to 3.9 and 3.10, and even then, I do not believe it should apply at all.

----------
nosy: +steven.daprano
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Tue Jul 14 19:14:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 14 Jul 2020 23:14:00 +0000
Subject: [issue41278] IDLE: Clarify some completion details in doc
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594768440.48.0.0223122217728.issue41278@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Although a few keystrokes are omitted, I reproduced the examples and can explain the results by elaborating on my claims above.

0. Python starts execution in module '__main__', which initially contains only double underscore names (now 7).

1. If a module name is not in the user code main namespace, IDLE checks in sys.modules, which initially contains '__main__' and many others.

2. 'fetch_completions' returns two completion lists: big, with all appropriate names, and small, without underscore names.  If big is not empty, the initial display is small if not empty, else big. 

Hence, at startup, '__main__.' displays the big list with 7 dunder names because small is empty.  Assign to *any* 'normal' name, so that small contains 1 name, and '__main__.' initially displays that 1 name.  There is nothing special about 'idlelib' here.

The above is true when editing.

3. When there is no Shell, there is no user process, the same as if one started IDLE with -n to never have a separate user process.  When there is no user process, completions are done in the IDLE GUI process, and its main module contains 'idlelib' from IDLE's startup imports.  So the small completion list contains 'idlelib'.

For '__main__.x' to run, there must be a previous 'import __main__'.  If one runs the editor code after entering import statements, as the doc recommends, a user process will be started.


*** I just edited the IDLE completion doc, but 1, 2, and 3 could be made clearer.  I am leaving this issue open to do so. ***

----------
stage:  -> needs patch
title: Wrong Completion on Editing Mode of IDLE -> IDLE: Clarify some completion details in doc
type: behavior -> enhancement
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Tue Jul 14 19:50:30 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Jul 2020 23:50:30 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1594770630.14.0.812330454603.issue41297@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Steven.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Tue Jul 14 21:23:31 2020
From: report at bugs.python.org (nirinA raseliarison)
Date: Wed, 15 Jul 2020 01:23:31 +0000
Subject: [issue41300] IDLE: missing import io in iomenu.py
Message-ID: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>


New submission from nirinA raseliarison <nirina.raseliarison at gmail.com>:

idle cannot save file with non ascii character, leading to:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib64/python3.8/tkinter/__init__.py", line 1883, in __call__
    return self.func(*args)
  File "/usr/lib64/python3.8/idlelib/multicall.py", line 176, in handler
    r = l[i](event)
  File "/usr/lib64/python3.8/idlelib/iomenu.py", line 199, in save
    else:
  File "/usr/lib64/python3.8/idlelib/iomenu.py", line 232, in writefile
    text = self.fixnewlines()
  File "/usr/lib64/python3.8/idlelib/iomenu.py", line 271, in encode
    encoded = chars.encode('ascii', 'replace')
NameError: name 'io' is not defined

just adding `import io` seems to fix this.

----------
assignee: terry.reedy
components: IDLE
messages: 373664
nosy: nirinA raseliarison, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: missing import io in iomenu.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Tue Jul 14 21:49:48 2020
From: report at bugs.python.org (paul j3)
Date: Wed, 15 Jul 2020 01:49:48 +0000
Subject: [issue9351] argparse set_defaults on subcommands should override top
 level set_defaults
In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za>
Message-ID: <1594777788.91.0.591166943861.issue9351@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

I just realized if the subparser argument used 

default=argparse.SUPPRESS

it would not clobber values (default or user) set by the main parser.

(a 'store_true' would have to be replaced with a 'store_const' to do this)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9351>
_______________________________________

From report at bugs.python.org  Tue Jul 14 23:39:20 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 15 Jul 2020 03:39:20 +0000
Subject: [issue41296] unittest.mock: patched mocks do not propagate calls to
 parent when set via setattr
In-Reply-To: <1594753439.43.0.455060750875.issue41296@roundup.psfhosted.org>
Message-ID: <1594784360.84.0.45335489713.issue41296@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41296>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:16:07 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Jul 2020 04:16:07 +0000
Subject: [issue41158] IDLE: rewrite the code for handling file encoding
In-Reply-To: <1593430677.27.0.733244762594.issue41158@roundup.psfhosted.org>
Message-ID: <1594786567.0.0.186211974227.issue41158@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#41300 reports that the new iomenu line 291
   enc, _ = tokenize.detect_encoding(io.BytesIO(encoded).readline)
fails without 'import io' added.  I should have tested more thoroughly.  I will fix and add tests there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41158>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:43:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Jul 2020 04:43:51 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594788231.91.0.0775920819953.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Your suggestion is correct.

A side issue is that the line numbers in the traceback are correct but the quoted text lines from iomenu (and only iomenu) are wrong, being from the line previous.  I will have to investigate this discrepancy.

After the patch, two weeks ago, for #41158, iomenu line 199 in save is
            if self.writefile(self.filename):
line 232 in writefile is 
        chars = self.encode(text)
line 291 in encode is
        enc, _ = tokenize.detect_encoding(io.BytesIO(encoded).readline)
This is only tried if ascii encoding fails and require the addition of 'import io'.

Before I close this, I will try to add a unittest that similarly fails without the import added, as well as some others for other exit points.

----------
stage:  -> test needed
title: IDLE: missing import io in iomenu.py -> IDLE: add missing import io in iomenu.py
type:  -> behavior
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Wed Jul 15 01:11:20 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 15 Jul 2020 05:11:20 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1594789880.78.0.4575307362.issue36346@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +20622
pull_request: https://github.com/python/cpython/pull/21479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Wed Jul 15 01:57:05 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 15 Jul 2020 05:57:05 +0000
Subject: [issue33007] Objects referencing private-mangled names do not
 roundtrip properly under pickling.
In-Reply-To: <1520314612.17.0.467229070634.issue33007@psf.upfronthosting.co.za>
Message-ID: <1594792625.23.0.708949653653.issue33007@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +20623
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21480

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33007>
_______________________________________

From report at bugs.python.org  Wed Jul 15 02:39:52 2020
From: report at bugs.python.org (Michiel de Hoon)
Date: Wed, 15 Jul 2020 06:39:52 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594795192.66.0.67127080519.issue41285@roundup.psfhosted.org>


Michiel de Hoon <mjldehoon at yahoo.com> added the comment:

Thank you, I have posted an explanation in the "Ideas" category of discuss.python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Wed Jul 15 02:45:50 2020
From: report at bugs.python.org (Yongjik Kim)
Date: Wed, 15 Jul 2020 06:45:50 +0000
Subject: [issue34624] -W option and PYTHONWARNINGS env variable does not
 accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1594795550.45.0.487103892346.issue34624@roundup.psfhosted.org>


Yongjik Kim <yongjik at gmail.com> added the comment:

Hi, sorry if I'm interrupting, but while we're at this, could we also not escape regex for "message" part?  (Or at least amend the documentation to clarify that the message part is literal string match?)

Currently, the docs on -W just say "The meaning of each of these fields is as described in The Warnings Filter" and then "The Warnings Filter" section says that the "message" field is a regex, but currently it's only true if you run warnings.filterwarnings() directly, and not if you use the -W option.

----------
nosy: +Yongjik Kim

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Wed Jul 15 02:47:01 2020
From: report at bugs.python.org (wyz23x2)
Date: Wed, 15 Jul 2020 06:47:01 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1594795621.2.0.516809360711.issue40360@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul 15 03:15:50 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Jul 2020 07:15:50 +0000
Subject: [issue41291] Race conditions when opening and deleting a file on Mac
 OS X
In-Reply-To: <1594649041.52.0.898762861377.issue41291@roundup.psfhosted.org>
Message-ID: <1594797350.89.0.135976676058.issue41291@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

If it is reproducable in C this is likely a bug in macOS, and should be reported to them. 

I get the same behaviour as you with the test script, even if I add calls to fhandle.flush and os.fsync to force the content to stable storage.

Interestingly enough I sometimes get other behaviour that shouldn't happen:

Traceback (most recent call last):
  File "/Users/ronald/Downloads/concurrency-tests/test-conc-read.py", line 33, in <module>
    fhandle.flush()
OSError: [Errno 22] Invalid argument

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "concurrency-tests/test-conc-read.py", line 34, in <module>
    os.fsync(fhandle.fileno())
OSError: [Errno 22] Invalid argument


This is with the change I wrote about earlier:

    except FileNotFoundError:
        print(i, ">> DELETED <<")
        # Recreate the file
        time.sleep(0.001) # Wait a bit
        with open(dest_fname, 'wb') as fhandle:
            fhandle.write(b'CONTENT')
            fhandle.flush()
            os.fsync(fhandle.fileno())

This shouldn't happen, "fhandle" is open at this point and hence the low-level file descriptor should still be valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41291>
_______________________________________

From report at bugs.python.org  Wed Jul 15 03:59:49 2020
From: report at bugs.python.org (Yashwanth Barad)
Date: Wed, 15 Jul 2020 07:59:49 +0000
Subject: [issue41301] Assignment operation of list is not working as expected
Message-ID: <1594799989.7.0.436076447294.issue41301@roundup.psfhosted.org>


Change by Yashwanth Barad <yashwanthbarad at gmail.com>:


----------
components: Windows
files: List_assignment_in_functions.py
nosy: paul.moore, steve.dower, tim.golden, yashwanthbarad at gmail.com, zach.ware
priority: normal
severity: normal
status: open
title: Assignment operation of list is not working as expected
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49317/List_assignment_in_functions.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41301>
_______________________________________

From report at bugs.python.org  Wed Jul 15 04:06:56 2020
From: report at bugs.python.org (Giovanni Pizzi)
Date: Wed, 15 Jul 2020 08:06:56 +0000
Subject: [issue41291] Race conditions when opening and deleting a file on Mac
 OS X
In-Reply-To: <1594649041.52.0.898762861377.issue41291@roundup.psfhosted.org>
Message-ID: <1594800416.35.0.205883834681.issue41291@roundup.psfhosted.org>


Giovanni Pizzi <gio.piz at gmail.com> added the comment:

Thanks for your feedback!

I also just reported the issue to Apple. For reference I got the Feedback ID FB8009608.

I will let you know if they answer.

In any case I agree that also your other error is unexpected.
I am writing a library that should provide atomicity guarantees and this issue is creating me a lot of headaches :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41291>
_______________________________________

From report at bugs.python.org  Wed Jul 15 04:28:02 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 15 Jul 2020 08:28:02 +0000
Subject: [issue41301] Assignment operation of list is not working as expected
Message-ID: <1594801682.82.0.757883400638.issue41301@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Sorry Yashwanthbarad, this isn't a bug, you expect the wrong result.

Augmented assignment for lists is documented to be the same as calling the extend method, which means your AppenedFuncShortHandOperator function modifies the argument list in-place.

The AppenedFuncRegularAssignment simply replaces the *local variable* inside the function with a new list. Since it doesn't return the new list, the new list gets thrown away when the function returns, leaving the original list untouched.

This is not a bug, it is the normal behaviour. If you need help understanding why it works the way it does, and the difference between mutating an object and binding a new object to a local variable, there are many places you can ask for help, such as Stackoverflow, the /learnpython sub-reddit on Reddit, the tutor mailing list and others.

https://mail.python.org/mailman/listinfo/tutor

Good luck!

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41301>
_______________________________________

From report at bugs.python.org  Wed Jul 15 05:07:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jul 2020 09:07:54 +0000
Subject: [issue20183] Derby #14: Convert 41 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140289.9.0.366061884326.issue20183@psf.upfronthosting.co.za>
Message-ID: <1594804074.14.0.741676108326.issue20183@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bbceef6851895135c80e588a55854c1afab46499 by Zackery Spytz in branch 'master':
bpo-20183: Convert _locale to the Argument Clinic (GH-14201)
https://github.com/python/cpython/commit/bbceef6851895135c80e588a55854c1afab46499


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20183>
_______________________________________

From report at bugs.python.org  Wed Jul 15 05:33:11 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 15 Jul 2020 09:33:11 +0000
Subject: [issue41278] IDLE: Clarify some completion details in doc
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594805591.93.0.348329284935.issue41278@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Terry, can we change the user process to be owned by the filelist rather than the shell to avoid this difference in behaviour? (I can't think of any reason off the top of my head of why this couldn't happen)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Wed Jul 15 05:50:06 2020
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 15 Jul 2020 09:50:06 +0000
Subject: [issue34624] -W option and PYTHONWARNINGS env variable does not
 accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1594806606.93.0.124551719305.issue34624@roundup.psfhosted.org>


Change by Nikolaus Rath <Nikolaus at rath.org>:


----------
nosy:  -nikratio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Wed Jul 15 06:25:55 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 10:25:55 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594808755.41.0.13486252466.issue41299@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Please provide the results of running the following with the two pythons you are using:

python -m test.pythoninfo

For what it's worth, running on macOS 10.15.5, I see a slight difference with more variability in the Python 3 results but nothing as pronounced as what you see. Also the Python 3 results were very similar across recent versions of 3.7.x, 3.8.x, and pre-release 3.9.

$ /usr/local/bin/python2.7 ~/test_41299.py | sort
0.017021894455
0.0170249938965
0.017028093338
0.017028093338
0.0170290470123
0.0170290470123
0.0170290470123
0.0170300006866
0.017030954361
0.0170311927795
[...]
0.0190448760986
0.0190479755402
0.0190498828888
0.0190510749817
0.0190589427948
0.019061088562
0.0190629959106
0.019079208374
0.0190861225128
0.0190970897675
End reached.0.0158078670502

$ /usr/local/bin/python3.8 ~/test_41299.py | sort
0.009722232818603516
0.017028093338012695
0.017033100128173828
0.017034053802490234
0.017034053802490234
0.017035961151123047
0.017037153244018555
0.017037153244018555
0.01703786849975586
0.017038822174072266
[...]
0.021351099014282227
0.021355152130126953
0.021355152130126953
0.02135610580444336
0.021361112594604492
0.021363258361816406
0.02136397361755371
0.021379947662353516
0.02138543128967285
0.021442890167236328
End reached.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 06:54:56 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 15 Jul 2020 10:54:56 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
Message-ID: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>


New submission from Felix Yan <felixonmars at archlinux.org>:

In bpo-40874, mpdecimal.h in the vendored libmpdec has defines of UNUSED while the standalone released version of mpdecimal 2.5.0 doesn't. This breaks _decimal module build with system libmpdec due to UNUSED is undefined.

Errors are like:

cpython/Modules/_decimal/_decimal.c:277:36: error: expected ?;?, ?,? or ?)? before ?UNUSED?
  277 | dec_traphandler(mpd_context_t *ctx UNUSED) /* GCOV_NOT_REACHED */
      |                                    ^~~~~~

Reproducible in both 3.8 branch and master (didn't test 3.9, but should be affected too).

----------
components: Extension Modules
messages: 373676
nosy: felixonmars, skrah
priority: normal
severity: normal
status: open
title: _decimal failed to build with system libmpdec 2.5
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:03:31 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 11:03:31 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594811011.86.0.474181084104.issue41302@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Thank you for the report, I'll add the define or remove UNUSED in 3.9
and 3.10.


3.8 is still supposed to use libmpdec-2.4.2, though it would be
harmless to use libmpdec-2.5.0.

Are you planning to use libmpdec-2.5.0 with 3.8?

----------
assignee:  -> skrah
stage:  -> needs patch
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:05:59 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 15 Jul 2020 11:05:59 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594811159.62.0.198671471955.issue41302@roundup.psfhosted.org>


Change by Felix Yan <felixonmars at archlinux.org>:


----------
keywords: +patch
pull_requests: +20624
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:07:59 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 15 Jul 2020 11:07:59 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594811279.08.0.248541196618.issue41302@roundup.psfhosted.org>


Felix Yan <felixonmars at archlinux.org> added the comment:

Yes, I am currently defining it manually as a workaround for building 3.8.4 in Arch.

Also opened GH-21481 for this :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:46:45 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 15 Jul 2020 11:46:45 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594813605.08.0.26665642077.issue41299@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I reproduced something similar on Python 3.9.0b1, Windows 64-bit version:

    py -m pyperf timeit -s "import threading; E = threading.Event()" "E.wait(<NUMBER>)"

NUMBER            Mean +- std dev
-------------------------------------------
0.0               5.79 us +- 0.13 us
0.000000000001    15.6 ms +- 0.1 ms
0.001             15.6 ms +- 0.1 ms
0.01              15.6 ms +- 0.6 ms
0.013             15.5 ms +- 0.6 ms
0.015             15.9 ms +- 0.9 ms
0.016             25.2 ms +- 0.5 ms
0.017             31.2 ms +- 0.2 ms
0.018             31.2 ms +- 0.4 ms
0.025             31.2 ms +- 1.0 ms
0.05              62.2 ms +- 0.8 ms
0.1               109 ms +- 2 ms
0.2               201 ms +- 3 ms
0.5               500 ms +- 0 ms
1.0               1.00 sec +- 0.00 sec

On the smaller scale, it looks quantized to multiples of ~15ms (?), but then it gets more accurate as the times get larger. I don't think it's a measurement error since the first measurement manages microseconds.

Perhaps this is just an OS-level thread-scheduling issue?

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:51:08 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 15 Jul 2020 11:51:08 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594813868.68.0.78858703501.issue39017@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 5a8d121a1f3ef5ad7c105ee378cc79a3eac0c7d4 by Rishi in branch 'master':
bpo-39017: Avoid infinite loop in the tarfile module (GH-21454)
https://github.com/python/cpython/commit/5a8d121a1f3ef5ad7c105ee378cc79a3eac0c7d4


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:51:26 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 11:51:26 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594813886.1.0.552600137561.issue39017@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +20626
pull_request: https://github.com/python/cpython/pull/21482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:51:33 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 11:51:33 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594813893.31.0.775933521132.issue39017@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20627
pull_request: https://github.com/python/cpython/pull/21483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:51:41 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 11:51:41 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594813901.25.0.307040071104.issue39017@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20628
pull_request: https://github.com/python/cpython/pull/21484

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 07:51:48 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 11:51:48 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594813908.94.0.23296276473.issue39017@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20629
pull_request: https://github.com/python/cpython/pull/21485

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:14:15 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 12:14:15 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594815255.28.0.0701787831554.issue41302@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 015efdbef7454a522e88cd79ba2b4cd77a5fb2a2 by Felix Yan in branch 'master':
bpo-41302: Fix build with system libmpdec (GH-21481)
https://github.com/python/cpython/commit/015efdbef7454a522e88cd79ba2b4cd77a5fb2a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:15:11 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 12:15:11 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594815311.51.0.12114556565.issue41302@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20630
pull_request: https://github.com/python/cpython/pull/21486

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:20:00 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 15 Jul 2020 12:20:00 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594815600.89.0.4558095575.issue39017@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Larry and Ned, do you want this fix in the security-only releases you manage?

PRs for 3.6 ad 3.7 are ready, should you wish to merge them.

----------
nosy: +larry, ned.deily -miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:30:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 12:30:36 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594816236.63.0.847785474058.issue39017@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f3232294ee695492f43d424cc6969d018d49861d by Miss Islington (bot) in branch '3.9':
[3.9] bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (GH-21482)
https://github.com/python/cpython/commit/f3232294ee695492f43d424cc6969d018d49861d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:30:57 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 12:30:57 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594816257.25.0.665505141302.issue39017@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c55479556db015f48fc8bbca17f64d3e65598559 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (GH-21483)
https://github.com/python/cpython/commit/c55479556db015f48fc8bbca17f64d3e65598559


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:34:22 2020
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 15 Jul 2020 12:34:22 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594816462.16.0.251002214178.issue39017@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Yes, please.  It's a simple low-risk fix.  And 3.5.10rc1 is stuck waiting for a fix anyway.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:35:12 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 12:35:12 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594816512.42.0.237717252369.issue39017@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 79c6b602efc9a906c8496f3d5f4d54c54b48fa06 by Miss Islington (bot) in branch '3.7':
bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (GH-21484)
https://github.com/python/cpython/commit/79c6b602efc9a906c8496f3d5f4d54c54b48fa06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:36:39 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 12:36:39 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594816599.78.0.365195382334.issue39017@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 47a2955589bdb1a114d271496ff803ad73f954b8 by Miss Islington (bot) in branch '3.6':
bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (#21485)
https://github.com/python/cpython/commit/47a2955589bdb1a114d271496ff803ad73f954b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:37:56 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 12:37:56 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594816676.31.0.530172332312.issue39017@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks, the PRs for 3.7 and 3.6 are now merged.

----------
versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:43:19 2020
From: report at bugs.python.org (nooB)
Date: Wed, 15 Jul 2020 12:43:19 +0000
Subject: [issue41303] perf_counter result does not count system sleep time in
 Mac OS
Message-ID: <1594816999.52.0.200760723432.issue41303@roundup.psfhosted.org>


New submission from nooB <nsharish.mit at gmail.com>:

Documentation for time.perf_counter says "does include time elapsed during sleep".

https://docs.python.org/3.8/library/time.html#time.perf_counter

But it does not work as expected in Mac OS. I learnt that perf_counter uses the underlying c function: "mach_absolute_time".

-------------------------

import time
time.get_clock_info('perf_counter')
namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)

-------------------------

The documentation for "mach_absolute_time" clearly states that "this clock does not increment while the system is asleep"

https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time


FWIW, Mac kernel does offer another function which returns monotonic ticks "including while the system is asleep"

https://developer.apple.com/documentation/kernel/1646199-mach_continuous_time

But it seems to be available only on Mac 10.12+.

----------
components: macOS
messages: 373690
nosy: ned.deily, nooB, ronaldoussoren
priority: normal
severity: normal
status: open
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41303>
_______________________________________

From report at bugs.python.org  Wed Jul 15 08:48:51 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 12:48:51 +0000
Subject: [issue41303] perf_counter result does not count system sleep time in
 Mac OS
In-Reply-To: <1594816999.52.0.200760723432.issue41303@roundup.psfhosted.org>
Message-ID: <1594817331.62.0.0333451192081.issue41303@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +belopolsky, p-ganssle, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41303>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:01:14 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 13:01:14 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594818074.34.0.59301803087.issue41302@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8ca63f95f769c31f65a996fe065ff6dcfb490bbe by Miss Islington (bot) in branch '3.9':
bpo-41302: Fix build with system libmpdec (GH-21481)
https://github.com/python/cpython/commit/8ca63f95f769c31f65a996fe065ff6dcfb490bbe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:18:27 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 13:18:27 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594819107.72.0.746990140771.issue41302@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Thanks for the patch!

The integrated libmpdec-2.4.2 in Python 3.8 still has a couple of
UNUSED, so the simple approach of moving the define would not work.
It would be easy to replace the few instances of UNUSED with void
casts like in 2.5.0.


Strictly speaking though, this would be a feature for 3.8 and not
a build fix.


On the other hand, if Debian also plans to use 2.5.0 with 3.8,
there would be a stronger case for this build feature.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:19:38 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 13:19:38 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594819178.5.0.301931131703.issue41302@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
resolution:  -> fixed
stage: patch review -> 
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:26:51 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 13:26:51 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594819611.66.0.902725059078.issue41285@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

If I understand this correctly, I think this may be a duplicate of #13797.


Something like a __getbuffer__ protocol would be needed. I'm not
saying we *should* go that route, just stating the requirements
from my perspective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:30:10 2020
From: report at bugs.python.org (SD)
Date: Wed, 15 Jul 2020 13:30:10 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594819810.74.0.595530170786.issue41299@roundup.psfhosted.org>


SD <scott-devine at hotmail.co.uk> added the comment:

I have tested this both on vs code terminal and cygwin for windows.

3.8.2 : 

python -m test.pythoninfo
Python debug information
========================

Py_DEBUG: No (sys.gettotalrefcount() missing)
_decimal.__libmpdec_version__: 2.4.2
builtins.float.double_format: IEEE, little-endian
builtins.float.float_format: IEEE, little-endian
datetime.datetime.now: 2020-07-15 09:09:34.936153
expat.EXPAT_VERSION: expat_2.2.8
locale.encoding: cp1252
os.cpu_count: 12
os.environ[APPDATA]: C:\Users\XXXX\AppData\Roaming
os.environ[COMPUTERNAME]: XXXX
os.environ[COMSPEC]: C:\Windows\system32\cmd.exe
os.environ[HOMEDRIVE]: C:
os.environ[HOMEPATH]: \Users\XXXX
os.environ[LANG]: en_GB.UTF-8
os.environ[PATHEXT]: .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW;.CPL
os.environ[PATH]: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\libnvvp;C:\Program Files\SlikSvn\bin;C:\Python\Python38\Scripts\;C:\Python\Python38\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\dotnet\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\Program Files (x86)\IncrediBuild;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Users\XXXX\AppData\Local\Microsoft\WindowsApps;;C:\Users\XXXX\AppData\Local\Programs\Microsoft VS Code\bin
os.environ[SYSTEMROOT]: C:\Windows
os.environ[TEMP]: C:\Users\XXXX\AppData\Local\Temp
os.environ[TMP]: C:\Users\XXXX\AppData\Local\Temp
os.environ[USERPROFILE]: C:\Users\XXXX
os.environ[WINDIR]: C:\Windows
os.getcwd: 
os.login: XXXX
os.name: nt
os.supports_bytes_environ: False
os.supports_effective_ids: []
os.supports_fd: ['stat', 'truncate']
os.supports_follow_symlinks: ['stat']
os.umask: 000
platform.architecture: 64bit WindowsPE
platform.platform: Windows-10-10.0.18362-SP0
platform.python_implementation: CPython
pymem.allocator: pymalloc
pymem.with_pymalloc: True
socket.hostname: 
sqlite3.sqlite_version: 3.28.0
sqlite3.version: 2.6.0
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1d  10 Sep 2019
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 4, 15)
ssl.OP_ALL: -0x7fffffac
ssl.OP_NO_TLSv1_1: 0x10000000
ssl.SSLContext.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.SSLContext.options: Options.OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION|OP_ALL
ssl.SSLContext.protocol: _SSLMethod.PROTOCOL_TLS
ssl.SSLContext.verify_mode: VerifyMode.CERT_NONE
ssl.default_https_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.default_https_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.default_https_context.options: Options.OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION|OP_ALL
ssl.default_https_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.default_https_context.verify_mode: VerifyMode.CERT_REQUIRED
ssl.stdlib_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.stdlib_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.stdlib_context.options: Options.OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION|OP_ALL
ssl.stdlib_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.stdlib_context.verify_mode: VerifyMode.CERT_NONE
subprocess._USE_POSIX_SPAWN: False
sys.api_version: 1013
sys.builtin_module_names: ('_abc', '_ast', '_bisect', '_blake2', '_codecs', '_codecs_cn', '_codecs_hk', '_codecs_iso2022', '_codecs_jp', '_codecs_kr', '_codecs_tw', '_collections', '_contextvars', '_csv', '_datetime', '_functools', '_heapq', '_imp', '_io', '_json', '_locale', '_lsprof', '_md5', '_multibytecodec', '_opcode', '_operator', '_pickle', '_random', '_sha1', '_sha256', '_sha3', '_sha512', '_signal', '_sre', '_stat', '_statistics', '_string', '_struct', '_symtable', '_thread', '_tracemalloc', '_warnings', '_weakref', '_winapi', '_xxsubinterpreters', 'array', 'atexit', 'audioop', 'binascii', 'builtins', 'cmath', 'errno', 'faulthandler', 'gc', 'itertools', 'marshal', 'math', 'mmap', 'msvcrt', 'nt', 'parser', 'sys', 'time', 'winreg', 'xxsubtype', 'zlib')
sys.byteorder: little
sys.dont_write_bytecode: False
sys.executable: C:\Python\Python38\python.exe
sys.filesystem_encoding: utf-8/surrogatepass
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=0)
sys.float_info: sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)
sys.float_repr_style: short
sys.hash_info: sys.hash_info(width=64, modulus=2305843009213693951, inf=314159, nan=0, imag=1000003, algorithm='siphash24', hash_bits=64, seed_bits=128, cutoff=0)
sys.hexversion: 50856688
sys.implementation: namespace(cache_tag='cpython-38', hexversion=50856688, name='cpython', version=sys.version_info(major=3, minor=8, micro=2, releaselevel='final', serial=0))
sys.int_info: sys.int_info(bits_per_digit=30, sizeof_digit=4)
sys.maxsize: 9223372036854775807
sys.maxunicode: 1114111
sys.path: ['C:\\Python\\Python38\\python38.zip', 'C:\\Python\\Python38\\DLLs', 'C:\\Python\\Python38\\lib', 'C:\\Python\\Python38', 'C:\\Users\\XXXX\\AppData\\Roaming\\Python\\Python38\\site-packages', 'C:\\Python\\Python38\\lib\\site-packages']
sys.platform: win32
sys.prefix: C:\Python\Python38
sys.stderr.encoding: utf-8/backslashreplace
sys.stdin.encoding: utf-8/surrogateescape
sys.stdout.encoding: utf-8/surrogateescape
sys.thread_info: sys.thread_info(name='nt', lock=None, version=None)
sys.version: 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)]
sys.version_info: sys.version_info(major=3, minor=8, micro=2, releaselevel='final', serial=0)
sys.windowsversion: sys.getwindowsversion(major=10, minor=0, build=18363, platform=2, service_pack='')
sys.winver: 3.8
sysconfig[prefix]: C:\Python\Python38
test_socket.HAVE_SOCKET_ALG: False
test_socket.HAVE_SOCKET_CAN: False
test_socket.HAVE_SOCKET_CAN_ISOTP: False
test_socket.HAVE_SOCKET_QIPCRTR: False
test_socket.HAVE_SOCKET_RDS: False
test_socket.HAVE_SOCKET_VSOCK: False
test_support.IPV6_ENABLED: True
test_support._is_gui_available: True
test_support.python_is_optimized: False
time.altzone: 14400
time.daylight: 1
time.get_clock_info(monotonic): namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015625)
time.get_clock_info(perf_counter): namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=1e-07)
time.get_clock_info(process_time): namespace(adjustable=False, implementation='GetProcessTimes()', monotonic=True, resolution=1e-07)
time.get_clock_info(thread_time): namespace(adjustable=False, implementation='GetThreadTimes()', monotonic=True, resolution=1e-07)
time.get_clock_info(time): namespace(adjustable=True, implementation='GetSystemTimeAsFileTime()', monotonic=False, resolution=0.015625)
time.time: 1594818575.0377405
time.timezone: 18000
time.tzname: ('Eastern Standard Time', 'Eastern Summer Time')
tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.9
windows.RtlAreLongPathsEnabled: True
windows.dll_path: C:\Python\Python38\python38.dll
zlib.ZLIB_RUNTIME_VERSION: 1.2.11
zlib.ZLIB_VERSION: 1.2.11


2.7.18 : 

 python -m test.pythoninfo
Python debug information
========================

Py_DEBUG: No (sys.gettotalrefcount() missing)
builtins.float.double_format: IEEE, little-endian
builtins.float.float_format: IEEE, little-endian
datetime.datetime.now: 2020-07-15 09:28:00.404000
expat.EXPAT_VERSION: expat_2.2.8
locale.encoding: cp1252
os.cwd: C:\Python\Python27
os.environ[APPDATA]: C:\Users\XXXX\AppData\Roaming
os.environ[COMPUTERNAME]: 
os.environ[COMSPEC]: C:\Windows\system32\cmd.exe
os.environ[HOMEDRIVE]: C:
os.environ[HOMEPATH]: \Users\XXXX
os.environ[PATHEXT]: .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW
os.environ[PATH]: C:\Program Files\ConEmu\ConEmu\Scripts;C:\Program Files\ConEmu;C:\Program Files\ConEmu\ConEmu;C:\Python\Python384\Scripts\;C:\Python\Python384\;C:\Users\XXXX\AppData\Local\Microsoft\WindowsApps;;C:\Users\XXXX\AppData\Local\Programs\Microsoft VS Code\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\libnvvp;C:\Program Files\SlikSvn\bin;C:\Python\Python38\Scripts\;C:\Python\Python38\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\dotnet\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\Program Files (x86)\IncrediBuild;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR
os.environ[SYSTEMROOT]: C:\Windows
os.environ[TEMP]: C:\Users\XXXX\AppData\Local\Temp
os.environ[TMP]: C:\Users\XXXX\AppData\Local\Temp
os.environ[USERPROFILE]: C:\Users\XXXX
os.environ[WINDIR]: C:\Windows
os.name: nt
os.umask: 000
platform.architecture: 64bit WindowsPE
platform.platform: Windows-10-10.0.18362
platform.python_implementation: CPython
socket.hostname: 
sqlite3.sqlite_version: 3.28.0
sqlite3.version: 2.6.0
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.0.2t  10 Sep 2019
ssl.OPENSSL_VERSION_INFO: (1, 0, 2, 20, 15)
ssl.OP_ALL: -0x7ffffc01
ssl.OP_NO_TLSv1_1: 0x10000000
ssl.SSLContext(PROTOCOL_TLS).options: OP_NO_SSLv3|OP_NO_SSLv2|OP_CIPHER_SERVER_PREFERENCE|OP_SINGLE_DH_USE|OP_SINGLE_ECDH_USE|OP_NO_COMPRESSION|OP_ALL
ssl.SSLContext(PROTOCOL_TLS).protocol: PROTOCOL_TLS
ssl.SSLContext(PROTOCOL_TLS).verify_mode: CERT_NONE
ssl.default_https_context.options: OP_NO_SSLv3|OP_NO_SSLv2|OP_CIPHER_SERVER_PREFERENCE|OP_SINGLE_DH_USE|OP_SINGLE_ECDH_USE|OP_NO_COMPRESSION|OP_ALL
ssl.default_https_context.protocol: PROTOCOL_TLS
ssl.default_https_context.verify_mode: CERT_REQUIRED
ssl.stdlib_context.options: OP_NO_SSLv3|OP_NO_SSLv2|OP_CIPHER_SERVER_PREFERENCE|OP_SINGLE_DH_USE|OP_SINGLE_ECDH_USE|OP_NO_COMPRESSION|OP_ALL
ssl.stdlib_context.protocol: PROTOCOL_TLS
ssl.stdlib_context.verify_mode: CERT_NONE
sys.api_version: 1013
sys.builtin_module_names: ('__builtin__', '__main__', '_ast', '_bisect', '_codecs', '_codecs_cn', '_codecs_hk', '_codecs_iso2022', '_codecs_jp', '_codecs_kr', '_codecs_tw', '_collections', '_csv', '_functools', '_heapq', '_hotshot', '_io', '_json', '_locale', '_lsprof', '_md5', '_multibytecodec', '_random', '_sha', '_sha256', '_sha512', '_sre', '_struct', '_subprocess', '_symtable', '_warnings', '_weakref', '_winreg', 'array', 'audioop', 'binascii', 'cPickle', 'cStringIO', 'cmath', 'datetime', 'errno', 'exceptions', 'future_builtins', 'gc', 'imageop', 'imp', 'itertools', 'marshal', 'math', 'mmap', 'msvcrt', 'nt', 'operator', 'parser', 'signal', 'strop', 'sys', 'thread', 'time', 'xxsubtype', 'zipimport', 'zlib')
sys.byteorder: little
sys.dont_write_bytecode: False
sys.executable: C:\Python\Python27\python.exe
sys.filesystem_encoding: mbcs
sys.flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
sys.float_info: sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)
sys.float_repr_style: short
sys.hexversion: 34018032
sys.maxsize: 9223372036854775807
sys.maxunicode: 65535
sys.path: ['', 'C:\\Windows\\SYSTEM32\\python27.zip', 'C:\\Python\\Python27\\DLLs', 'C:\\Python\\Python27\\lib', 'C:\\Python\\Python27\\lib\\plat-win', 'C:\\Python\\Python27\\lib\\lib-tk', 'C:\\Python\\Python27', 'C:\\Python\\Python27\\lib\\site-packages']
sys.platform: win32
sys.prefix: C:\Python\Python27
sys.stderr.encoding: cp850
sys.stdin.encoding: cp850
sys.stdout.encoding: cp850
sys.version: 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)]
sys.version_info: sys.version_info(major=2, minor=7, micro=18, releaselevel='final', serial=0)
sys.windowsversion: sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, service_pack='')
sys.winver: 2.7
sysconfig[prefix]: C:\Python\Python27
test_support.IPV6_ENABLED: True
test_support._is_gui_available: True
test_support.python_is_optimized: False
time.altzone: 14400
time.daylight: 1
time.time: 1594819680.4
time.timezone: 18000
time.tzname: ('Eastern Standard Time', 'Eastern Summer Time')
tkinter.TCL_VERSION: 8.5
tkinter.TK_VERSION: 8.5
zlib.ZLIB_VERSION: 1.2.11

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:44:55 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 13:44:55 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594820695.1.0.670185627459.issue41299@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the version info.

Windows and/or threading experts: any ideas?

----------
components: +Library (Lib), Windows
nosy: +paul.moore, pitrou, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 09:59:52 2020
From: report at bugs.python.org (=?utf-8?q?Jonas_Sch=C3=A4fer?=)
Date: Wed, 15 Jul 2020 13:59:52 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594821592.78.0.332834344667.issue41295@roundup.psfhosted.org>


Change by Jonas Sch?fer <jonas at zombofant.net>:


----------
nosy: +jssfr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:11:50 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Jul 2020 14:11:50 +0000
Subject: [issue41291] Race conditions when opening and deleting a file on Mac
 OS X
In-Reply-To: <1594649041.52.0.898762861377.issue41291@roundup.psfhosted.org>
Message-ID: <1594822310.48.0.967805285954.issue41291@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a variation on test-conc-read.py that uses os.open and low-level APIs instead of the Python IO stack (open/io.open).  This fails in the same way.

os.open/os.read/os.write/os.close are very thin wrappers around the corresponding C APIs. That clearly indicates that there is a bug in the OS.

----------
Added file: https://bugs.python.org/file49318/test-conc-read2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41291>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:13:53 2020
From: report at bugs.python.org (Michiel de Hoon)
Date: Wed, 15 Jul 2020 14:13:53 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594822433.52.0.0142432733876.issue41285@roundup.psfhosted.org>


Michiel de Hoon <mjldehoon at yahoo.com> added the comment:

You are correct, this is indeed a duplicate of #13797. My apologies for not finding this issue before opening a new one. If there are no objections, I will close this issue as a duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:41:17 2020
From: report at bugs.python.org (Jimmy Girardet)
Date: Wed, 15 Jul 2020 14:41:17 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file
Message-ID: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>


New submission from Jimmy Girardet <ijkl at netc.fr>:

Hi,
With python embed unziped in `38` directory(python 3.8.4):

```
# python38._pth
python38.zip
.
..\\app
# Uncomment to run site.main() automatically
#import site
```

```
PS C:\Users\jimmy\rien\embed> .\38\python.exe -c "import sys;print(sys.path);import hello"
['', 'C:\\Users\\jimmy\\rien\\embed\\38\\python38.zip', 'C:\\Users\\jimmy\\rien\\embed\\38\\DLLs', 'C:\\Users\\jimmy\\ri
en\\embed\\38\\lib', 'C:\\Users\\jimmy\\rien\\embed\\38']
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'hello'


'\\app' is not added to sys.path. it is under python 3.
```

Note It's working under python 3.7.8

----------
components: Interpreter Core
messages: 373698
nosy: jgirardet
priority: normal
severity: normal
status: open
title: python 38 embed ignore python38._pth file
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:41:43 2020
From: report at bugs.python.org (Jimmy Girardet)
Date: Wed, 15 Jul 2020 14:41:43 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594824103.64.0.013043216168.issue41304@roundup.psfhosted.org>


Change by Jimmy Girardet <ijkl at netc.fr>:


----------
title: python 38 embed ignore python38._pth file -> python 38 embed ignore python38._pth file on windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:05:37 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 15 Jul 2020 15:05:37 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594825537.81.0.872787014515.issue41302@roundup.psfhosted.org>


Change by Felix Yan <felixonmars at archlinux.org>:


----------
pull_requests: +20631
status: pending -> open
pull_request: https://github.com/python/cpython/pull/21488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:20:55 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Jul 2020 15:20:55 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1594826455.93.0.390580034619.issue41271@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

How stable is the io_uring API?

The stdlib evolves slowly, I'm not sure if the io_uring interface has matured enough to make it acceptable that updates to the stdlib bindings for that API are only done in new major releases of CPython (about every 18 months). 

It is probably better to create a PyPI package for this API. This package can then also provide an asyncio eventloop implementation.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:21:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 15:21:54 +0000
Subject: [issue41291] Race conditions when opening and deleting a file on Mac
 OS X
In-Reply-To: <1594649041.52.0.898762861377.issue41291@roundup.psfhosted.org>
Message-ID: <1594826514.28.0.829416086089.issue41291@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I was able to easily reproduce it as well. I suppose we all tested on very fast SSD-based APFS file systems.  I wonder if the problem might be file system related. I wasn?t able to reproduce it using a HDD-based HFS+ file system but it might just be due to the speed difference. In any case, I agree it?s up to Apple to resolve. Let us know when you hear something back from Apple.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41291>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:29:04 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 15 Jul 2020 15:29:04 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594826944.12.0.349893174596.issue39017@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +20632
pull_request: https://github.com/python/cpython/pull/21489

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:32:39 2020
From: report at bugs.python.org (Jimmy Girardet)
Date: Wed, 15 Jul 2020 15:32:39 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594827159.82.0.464595029913.issue41304@roundup.psfhosted.org>


Jimmy Girardet <ijkl at netc.fr> added the comment:

replacing python38._pth by python._pth does fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:39:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 15 Jul 2020 15:39:45 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594827585.25.0.571515579496.issue41304@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 12:16:44 2020
From: report at bugs.python.org (Tony)
Date: Wed, 15 Jul 2020 16:16:44 +0000
Subject: [issue41305] Add StreamReader.readinto()
Message-ID: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>


New submission from Tony <tony.solomonik at gmail.com>:

Add a StreamReader.readinto(buf) function.

Exactly like StreamReader.read() with *n* being equal to the length of buf.

Instead of allocating a new buffer, copy the read buffer into buf.

----------
messages: 373702
nosy: tontinton
priority: normal
severity: normal
status: open
title: Add StreamReader.readinto()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 12:28:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 15 Jul 2020 16:28:43 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594830523.45.0.102634513653.issue41305@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +asyncio
nosy: +asvetlov, yselivanov
type:  -> enhancement
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:06:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jul 2020 17:06:15 +0000
Subject: [issue23860] Windows: Failure to check return value from lseek() in
 Modules/mmapmodule.c
In-Reply-To: <1428083040.47.0.668729418368.issue23860@psf.upfronthosting.co.za>
Message-ID: <1594832775.05.0.824154614746.issue23860@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23860>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:08:02 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Jul 2020 17:08:02 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1594832882.37.0.842082925689.issue41271@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

I agree that adding stdlib support is premature. io_uring has a large and growing API surface. It will take some experimentation to see what the best way to expose its power to Python is.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:35:49 2020
From: report at bugs.python.org (Cooper Lees)
Date: Wed, 15 Jul 2020 17:35:49 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1594834549.97.0.360043075991.issue41271@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

Totally agree with a separate module first to POC. I should have stated that. Main goal was to open this issue to start discussions :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:36:54 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 17:36:54 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594834614.4.0.600311255963.issue41285@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Yes, let's make #13797 a superseder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:38:42 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 17:38:42 +0000
Subject: [issue41285] memoryview does not support subclassing
In-Reply-To: <1594563804.44.0.878376005542.issue41285@roundup.psfhosted.org>
Message-ID: <1594834722.14.0.012948069811.issue41285@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Allow objects implemented in pure Python to export PEP 3118 buffers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41285>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:40:46 2020
From: report at bugs.python.org (Tony)
Date: Wed, 15 Jul 2020 17:40:46 +0000
Subject: [issue41279] Convert StreamReaderProtocol to a BufferedProtocol
In-Reply-To: <1594484620.37.0.437755734421.issue41279@roundup.psfhosted.org>
Message-ID: <1594834846.26.0.936447049051.issue41279@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
pull_requests: +20633
pull_request: https://github.com/python/cpython/pull/21491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41279>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:41:17 2020
From: report at bugs.python.org (Tony)
Date: Wed, 15 Jul 2020 17:41:17 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594834877.38.0.8675513753.issue41305@roundup.psfhosted.org>


Change by Tony <tony.solomonik at gmail.com>:


----------
keywords: +patch
pull_requests: +20634
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:51:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jul 2020 17:51:11 +0000
Subject: [issue33007] Objects referencing private-mangled names do not
 roundtrip properly under pickling.
In-Reply-To: <1520314612.17.0.467229070634.issue33007@psf.upfronthosting.co.za>
Message-ID: <1594835471.4.0.415680591166.issue33007@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.10 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33007>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:07:59 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 18:07:59 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594836479.37.0.953992576019.issue41304@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, this is a regression.

https://github.com/python/cpython/blob/master/PC/getpathp.c#L672 should be inverted, as a zero return value indicates success.

----------
keywords: +3.8regression
versions: +Python 3.10, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:08:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 18:08:21 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594836501.8.0.0885040225027.issue41304@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
stage:  -> test needed
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:11:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 18:11:47 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594836707.49.0.761027551321.issue41299@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

At a guess, it's probably the signal emulation (a.k.a. Ctrl+C support). We could save some time by checking the requested handle first without blocking, and only beginning the blocking call if it's not available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:43:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jul 2020 18:43:07 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1594838587.97.0.832248445976.issue40150@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset af4eda46d1538b1da700a86588bdb94b0a4d1ff2 by Zackery Spytz in branch 'master':
bpo-40150: Fix mismatched argument in RegisterWaitForSingleObject() call (GH-19686)
https://github.com/python/cpython/commit/af4eda46d1538b1da700a86588bdb94b0a4d1ff2


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:43:19 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 18:43:19 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1594838599.4.0.862790547905.issue40150@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20635
pull_request: https://github.com/python/cpython/pull/21493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:43:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 18:43:27 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1594838607.28.0.0860098324671.issue40150@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20636
pull_request: https://github.com/python/cpython/pull/21494

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Wed Jul 15 14:56:12 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Jul 2020 18:56:12 +0000
Subject: [issue41291] Race conditions when opening and deleting a file on Mac
 OS X
In-Reply-To: <1594649041.52.0.898762861377.issue41291@roundup.psfhosted.org>
Message-ID: <1594839372.52.0.638658545817.issue41291@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This appears to be a bug in the APFS filesystem implementation.

On my machine:
- main disk (SSD, APFS): race condition happens
- r/w disk image with APFS: race condition happens
- r/w disk image with HFS+: no race condition

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41291>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:12:33 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 15 Jul 2020 19:12:33 +0000
Subject: [issue41306] test_tk failure on Arch Linux
Message-ID: <1594840353.83.0.567403527611.issue41306@roundup.psfhosted.org>


New submission from Felix Yan <felixonmars at archlinux.org>:

test_from (tkinter.test.test_tkinter.test_widgets.ScaleTest) is currently failing on Arch Linux, and at least another place: https://python-build-standalone.readthedocs.io/en/latest/status.html

The error looks like:

======================================================================
FAIL: test_from (tkinter.test.test_tkinter.test_widgets.ScaleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.8/tkinter/test/test_tkinter/test_widgets.py", line 939, in test_from
    self.checkFloatParam(widget, 'from', 100, 14.9, 15.1, conv=float_round)
  File "/usr/lib/python3.8/tkinter/test/widget_tests.py", line 106, in checkFloatParam
    self.checkParam(widget, name, value, conv=conv, **kwargs)
  File "/usr/lib/python3.8/tkinter/test/widget_tests.py", line 64, in checkParam
    self.assertEqual2(widget.cget(name), expected, eq=eq)
  File "/usr/lib/python3.8/tkinter/test/widget_tests.py", line 47, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 14.9 != 15.0

It's the only failure in the current Python 3.8.4 release's test suite here. Also adding Python 3.9 and 3.10 as I am able to reproduce it on master too.

----------
components: Tests
messages: 373710
nosy: felixonmars
priority: normal
severity: normal
status: open
title: test_tk failure on Arch Linux
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41306>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:18:03 2020
From: report at bugs.python.org (Dieter Maurer)
Date: Wed, 15 Jul 2020 19:18:03 +0000
Subject: [issue41307] "email.message.Message.as_bytes": fails to correctly
 handle "charset"
Message-ID: <1594840683.21.0.418149762397.issue41307@roundup.psfhosted.org>


New submission from Dieter Maurer <dieter at handshake.de>:

In the transscript below, "ms" and "mb" should be equivalent:

>>> from email import message_from_string, message_from_bytes
>>> mt = """\
... Mime-Version: 1.0
... Content-Type: text/plain; charset=UTF-8
... Content-Transfer-Encoding: 8bit
... 
... ?
... """
>>> ms = message_from_string(mt)
>>> mb = message_from_bytes(mt.encode("UTF-8"))

But "mb.as_bytes" succeeds while "ms.as_bytes" raises a "UnicodeEncodeError":

>>> mb.as_bytes()
b'Mime-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\xc3\xa4\n'
>>> ms.as_bytes()
Traceback (most recent call last):
...
  File "/usr/local/lib/python3.9/email/generator.py", line 155, in _write_lines
    self.write(line)
  File "/usr/local/lib/python3.9/email/generator.py", line 406, in write
    self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 0: ordinal not in range(128)

Apparently, the "as_bytes" ignores the "charset" parameter from the "Content-Type" header (it should use "utf-8", not "ascii" for the encoding).

----------
components: email
messages: 373711
nosy: barry, dmaurer, r.david.murray
priority: normal
severity: normal
status: open
title: "email.message.Message.as_bytes":  fails to correctly handle "charset"
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41307>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:25:59 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 19:25:59 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1594841159.04.0.762302191855.issue40150@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f8055fb0f1054fce6a21047da39b92ae32416b80 by Miss Islington (bot) in branch '3.8':
bpo-40150: Fix mismatched argument in RegisterWaitForSingleObject() call (GH-19686)
https://github.com/python/cpython/commit/f8055fb0f1054fce6a21047da39b92ae32416b80


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:26:06 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 19:26:06 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1594841166.07.0.469072452983.issue40150@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4a02da4f95cfff679e38a13ca0f44d660c5669b5 by Miss Islington (bot) in branch '3.9':
bpo-40150: Fix mismatched argument in RegisterWaitForSingleObject() call (GH-19686)
https://github.com/python/cpython/commit/4a02da4f95cfff679e38a13ca0f44d660c5669b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:31:43 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 19:31:43 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594841503.78.0.93533301106.issue41304@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20637
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21495

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:36:09 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 15 Jul 2020 19:36:09 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594841769.45.0.818871055592.issue41305@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

We don't want to extend StreamReader with new APIs as ultimately we plan to deprecate it. A new streams API is needed, perhaps inspired by Trio. Sadly, I'm -1 on this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:51:41 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Wed, 15 Jul 2020 19:51:41 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1594842701.14.0.08913980287.issue39093@roundup.psfhosted.org>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

I stumbled into this in another project and I want to +1 the uncommenting solution. The problem occurs on __del__ rather than specifically in the gc somewhere (it happens when refs drop to zero too), so I wouldn't worry too much about killing the garbage collector.

It also looks like fixing the python part would be about 3 lines of non-user-facing code with weakrefs. Are you sure that's no-go?

Would it be any help to roll this fix into https://bugs.python.org/issue41176 and https://github.com/python/cpython/pull/21299 since we fixed the quit() docs there?

----------
nosy: +Richard Sheridan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:51:53 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Wed, 15 Jul 2020 19:51:53 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1594842713.34.0.898310994916.issue39093@roundup.psfhosted.org>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

I stumbled into this in another project and I want to +1 the uncommenting solution. The problem occurs on __del__ rather than specifically in the gc somewhere (it happens when refs drop to zero too), so I wouldn't worry too much about killing the garbage collector.

It also looks like fixing the python part would be about 3 lines of non-user-facing code with weakrefs. Are you sure that's no-go?

Would it be any help to roll this fix into https://bugs.python.org/issue41176 and https://github.com/python/cpython/pull/21299 since we fixed the quit() docs there?

----------
nosy: +Richard Sheridan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:53:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jul 2020 19:53:03 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1594842783.99.0.540153379415.issue40150@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:54:27 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Wed, 15 Jul 2020 19:54:27 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1594842867.1.0.921044876955.issue39093@roundup.psfhosted.org>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

I stumbled into this in another project and I want to +1 the uncommenting solution. The problem occurs on __del__ rather than specifically in the gc somewhere (it happens when refs drop to zero too), so I wouldn't worry too much about killing the garbage collector.

It also looks like fixing the python part would be about 3 lines of non-user-facing code with weakrefs. Are you sure that's no-go?

Would it be any help to roll this fix into https://bugs.python.org/issue41176 and https://github.com/python/cpython/pull/21299 since we fixed the quit() docs there?

----------
nosy: +Richard Sheridan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Wed Jul 15 15:56:43 2020
From: report at bugs.python.org (Richard Sheridan)
Date: Wed, 15 Jul 2020 19:56:43 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1594843003.2.0.709518009366.issue39093@roundup.psfhosted.org>


Richard Sheridan <richard.sheridan at gmail.com> added the comment:

I stumbled into this in another project and I want to +1 the uncommenting solution. The problem occurs on __del__ rather than specifically in the gc somewhere (it happens when refs drop to zero too), so I wouldn't worry too much about killing the garbage collector.

It also looks like fixing the python part would be about 3 lines of non-user-facing code with weakrefs. Are you sure that's no-go?

Would it be any help to roll this fix into https://bugs.python.org/issue41176 and https://github.com/python/cpython/pull/21299 since we fixed the quit() docs there?

----------
nosy: +Richard Sheridan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Wed Jul 15 16:01:29 2020
From: report at bugs.python.org (Tony)
Date: Wed, 15 Jul 2020 20:01:29 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594843289.78.0.0873260869447.issue41305@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

ok.

Im interested in learning about the new api.
Is it documented somewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 16:02:17 2020
From: report at bugs.python.org (Tony)
Date: Wed, 15 Jul 2020 20:02:17 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594843337.95.0.550492374066.issue41305@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

Ah it's trio...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 16:04:21 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 20:04:21 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594843461.07.0.238510567462.issue41302@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I'm going to reclassify this as a build fix for 3.8. 3.8 promises:

#if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x02040100
  #error "libmpdec version >= 2.4.1 required"
#endif

So it seems reasonable to support at least two or three consecutive
system libmpdec versions, otherwise the >= is pointless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 16:22:30 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 20:22:30 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594844550.51.0.60077312734.issue41302@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 16eea45fbd3b7c3d1b222b7eb7a5d7ee427f70bd by Felix Yan in branch '3.8':
[3.8] bpo-41302: Support system libmpdec 2.5 for Python 3.8 (GH-21488)
https://github.com/python/cpython/commit/16eea45fbd3b7c3d1b222b7eb7a5d7ee427f70bd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 16:30:40 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Jul 2020 20:30:40 +0000
Subject: [issue41302] _decimal failed to build with system libmpdec 2.5
In-Reply-To: <1594810496.64.0.595713191405.issue41302@roundup.psfhosted.org>
Message-ID: <1594845040.36.0.918202783528.issue41302@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Closing, thanks for all the patches!

----------
stage:  -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41302>
_______________________________________

From report at bugs.python.org  Wed Jul 15 16:40:58 2020
From: report at bugs.python.org (Dieter Maurer)
Date: Wed, 15 Jul 2020 20:40:58 +0000
Subject: [issue41307] "email.message.Message.as_bytes": fails to correctly
 handle "charset"
In-Reply-To: <1594840683.21.0.418149762397.issue41307@roundup.psfhosted.org>
Message-ID: <1594845658.73.0.543056076491.issue41307@roundup.psfhosted.org>


Dieter Maurer <dieter at handshake.de> added the comment:

The following fixes the example:
from copy import copy
from io import BytesIO
from email.message import Message
from email.generator import BytesGenerator, _has_surrogates
from email._policybase import Compat32


class FixedBytesGenerator(BytesGenerator):
    def _handle_text(self, msg):
        payload = msg._payload
        if payload is None:
            return
        charset = msg.get_param("charset")
        if charset is not None \
               and not self.policy.cte_type=='7bit' \
               and not _has_surrogates(payload):
            msg = copy(msg)
            msg._payload = payload.encode(charset).decode(
                "ascii", "surrogateescape")
        super()._handle_text(msg)
                
    _writeBody = _handle_text


class FixedMessage(Message):
    def as_bytes(self, unixfrom=False, policy=None):
        policy = self.policy if policy is None else policy
        fp = BytesIO()
        g = FixedBytesGenerator(fp, mangle_from_=False, policy=policy)
        g.flatten(self, unixfrom=unixfrom)
        return fp.getvalue()
        

fixed_policy = Compat32(message_factory=FixedMessage)

ms = message_from_string(mt, policy=fixed_policy)
ms.as_bytes()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41307>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:21:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 21:21:16 +0000
Subject: [issue41308] socket.connect() slow to time out on Windows
Message-ID: <1594848076.72.0.0566311490676.issue41308@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

When connecting to localhost, socket.connect() takes two seconds on Windows (the default) to time out, but on Linux (including WSL) it times out immediately.

Test code (assuming port 9999 has no listener):
>>> import socket
>>> socket.socket().connect(('localhost', 9999))

For a remote host, the timeout is approx 10s on Windows and 20s on WSL (I didn't test on a native Linux box).

I'm told the correct fix is to specify TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS [1] when connecting to localhost.

----------
components: Windows
messages: 373725
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: socket.connect() slow to time out on Windows
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41308>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:56:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 21:56:13 +0000
Subject: [issue41309] test_subprocess timing out randomly on Windows
Message-ID: <1594850173.83.0.809593966079.issue41309@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Spotted at https://dev.azure.com/Python/cpython/_build/results?buildId=66387&view=logs&j=d554cd63-f8f4-5b2d-871b-33e4ea76e915&t=5a14d0eb-dbd4-5b80-f5d0-7909f950a1cc&l=1859

test_empty_input (test.test_asyncio.test_subprocess.SubprocessProactorTests) ... ok
test_exec_loop_deprecated (test.test_asyncio.test_subprocess.SubprocessProactorTests) ... ok
test_kill (test.test_asyncio.test_subprocess.SubprocessProactorTests) ... ok
Warning -- Unraisable exception
Warning -- Unraisable exception
Timeout (0:20:00)!
Thread 0x00001eac (most recent call first):
  File "D:\a\1\s\lib\asyncio\windows_events.py", line 779 in _poll
  File "D:\a\1\s\lib\asyncio\windows_events.py", line 430 in select
  File "D:\a\1\s\lib\asyncio\base_events.py", line 1854 in _run_once
  File "D:\a\1\s\lib\asyncio\base_events.py", line 596 in run_forever
  File "D:\a\1\s\lib\asyncio\windows_events.py", line 316 in run_forever
  File "D:\a\1\s\lib\asyncio\base_events.py", line 629 in run_until_complete
  File "D:\a\1\s\lib\test\test_asyncio\test_subprocess.py", line 302 in test_pause_reading
  File "D:\a\1\s\lib\unittest\case.py", line 549 in _callTestMethod
  File "D:\a\1\s\lib\unittest\case.py", line 592 in run
  File "D:\a\1\s\lib\unittest\case.py", line 652 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\runner.py", line 176 in run
  File "D:\a\1\s\lib\test\support\__init__.py", line 975 in _run_suite
  File "D:\a\1\s\lib\test\support\__init__.py", line 1098 in run_unittest
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 211 in _test_module
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 236 in _runtest_inner2
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 272 in _runtest_inner
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 155 in _runtest
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 195 in runtest
  File "D:\a\1\s\lib\test\libregrtest\main.py", line 319 in rerun_failed_tests
  File "D:\a\1\s\lib\test\libregrtest\main.py", line 696 in _main
  File "D:\a\1\s\lib\test\libregrtest\main.py", line 639 in main
  File "D:\a\1\s\lib\test\libregrtest\main.py", line 717 in main
  File "D:\a\1\s\lib\test\__main__.py", line 2 in <module>
  File "D:\a\1\s\lib\runpy.py", line 87 in _run_code
  File "D:\a\1\s\lib\runpy.py", line 197 in _run_module_as_main
##[error]Cmd.exe exited with code '1'.

----------
components: Tests, Windows
messages: 373726
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_subprocess timing out randomly on Windows
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41309>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:56:29 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 21:56:29 +0000
Subject: [issue41309] test_subprocess timing out randomly on Windows
In-Reply-To: <1594850173.83.0.809593966079.issue41309@roundup.psfhosted.org>
Message-ID: <1594850189.9.0.113629307556.issue41309@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20638
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21495

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41309>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:56:55 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 21:56:55 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594850215.95.0.543051376622.issue41304@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 936a66094591dc0e67d4a60c170148bb700ec016 by Steve Dower in branch 'master':
bpo-41304: Ensure python3x._pth is loaded on Windows (GH-21495)
https://github.com/python/cpython/commit/936a66094591dc0e67d4a60c170148bb700ec016


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:57:05 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 21:57:05 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594850225.24.0.565497264429.issue41304@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +20639
pull_request: https://github.com/python/cpython/pull/21497

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:57:14 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 21:57:14 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594850234.18.0.680740576056.issue41304@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20640
pull_request: https://github.com/python/cpython/pull/21498

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 17:59:59 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 21:59:59 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594850399.79.0.268826364498.issue41304@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20641
pull_request: https://github.com/python/cpython/pull/21499

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:01:29 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jul 2020 22:01:29 +0000
Subject: [issue41309] test_subprocess.test_pause_reading timing out randomly
 on Windows
In-Reply-To: <1594850173.83.0.809593966079.issue41309@roundup.psfhosted.org>
Message-ID: <1594850489.36.0.020131177572.issue41309@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
title: test_subprocess timing out randomly on Windows -> test_subprocess.test_pause_reading timing out randomly on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41309>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:14:55 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 22:14:55 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594851295.97.0.19545969428.issue41304@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 28e93dd2b26c460424acbebd00d8b943abbbea17 by Miss Islington (bot) in branch '3.9':
bpo-41304: Ensure python3x._pth is loaded on Windows (GH-21495)
https://github.com/python/cpython/commit/28e93dd2b26c460424acbebd00d8b943abbbea17


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:15:45 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jul 2020 22:15:45 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594851345.57.0.643739071397.issue41304@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3b6a8d2455c6897085f4277737b0f9b9a3847c24 by Miss Islington (bot) in branch '3.8':
bpo-41304: Ensure python3x._pth is loaded on Windows (GH-21495)
https://github.com/python/cpython/commit/3b6a8d2455c6897085f4277737b0f9b9a3847c24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:21:55 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 15 Jul 2020 22:21:55 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
Message-ID: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

See https://lemire.me/blog/2020/03/10/fast-float-parsing-in-practice/ for inspiration and a reference (possibly a library to use, but if not the techniques still apply).

Primarily usable when creating the float objects from the string data as is common in python code and particularly common in JSON serialized data.

----------
components: Interpreter Core
messages: 373730
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: micro-optimization: increase our float parsing speed by Nx
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:24:59 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jul 2020 22:24:59 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594851899.8.0.0481810685817.issue41304@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 4bfcffe16e9742c154f54ae96b5b36903500abaa by Steve Dower in branch '3.7':
bpo-41304: Ensure python3x._pth is loaded on Windows (GH-21495) (#21499)
https://github.com/python/cpython/commit/4bfcffe16e9742c154f54ae96b5b36903500abaa


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Wed Jul 15 19:09:53 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 15 Jul 2020 23:09:53 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
In-Reply-To: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>
Message-ID: <1594854593.46.0.0700137003932.issue41310@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Wed Jul 15 19:25:03 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 15 Jul 2020 23:25:03 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594855503.19.0.209609552026.issue41305@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Im interested in learning about the new api.

There are two problems with the current API:

1. Reader and writer are separate objects, while they should be one.
2. Writer.write is not a coroutine, although it should be one.

There are other minor nits, but that's the crux of the problem. So we need a new streams design + a new set of APIs to work with it (and streams are in many places, like in the subprocess APIs).

Trio was going to stabilize their own streaming API and we thought it would be great if our new API was compatible with it (not sure if they did stabilize it or not).

I was going to lead the project myself (and still am) but dropped the ball and we missed 3.9 to do this. If you want to start working on this I'd be glad to assist with discussions & reviews.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Wed Jul 15 20:10:31 2020
From: report at bugs.python.org (Oscar Benjamin)
Date: Thu, 16 Jul 2020 00:10:31 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
Message-ID: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>


New submission from Oscar Benjamin <oscar.j.benjamin at gmail.com>:

The random.choice/random.sample functions will only accept a sequence to select from. Can there be a function in the random module for selecting from an arbitrary iterable?

It is possible to make an efficient function that can make random selections from an arbitrary iterable e.g.:


from math import exp, log, floor
from random import random, randrange
from itertools import islice

def sample_iter(iterable, k=1):
    """Select k items uniformly from iterable.

    Returns the whole population if there are k or fewer items
    """
    iterator = iter(iterable)
    values = list(islice(iterator, k))

    W = exp(log(random())/k)
    while True:
        # skip is geometrically distributed
        skip = floor( log(random())/log(1-W) )
        selection = list(islice(iterator, skip, skip+1))
        if selection:
            values[randrange(k)] = selection[0]
            W *= exp(log(random())/k)
        else:
            return values


https://en.wikipedia.org/wiki/Reservoir_sampling#An_optimal_algorithm


This could be used for random sampling from sets/dicts or also to choose something like a random line from a text file. The algorithm needs to fully consume the iterable but does so efficiently using islice. In the case of a dict this is faster than converting to a list and using random.choice:


In [2]: n = 6

In [3]: d = dict(zip(range(10**n), range(10**n)))

In [4]: %timeit sample_iter(d)
15.5 ms ? 326 ?s per loop (mean ? std. dev. of 7 runs, 100 loops each

In [5]: %timeit list(d)
26.1 ms ? 1.72 ms per loop (mean ? std. dev. of 7 runs, 10 loops each)

In [6]: %timeit sample_iter(d, 2)
15.8 ms ? 427 ?s per loop (mean ? std. dev. of 7 runs, 100 loops each)

In [7]: %timeit sample_iter(d, 20)
17.6 ms ? 2.17 ms per loop (mean ? std. dev. of 7 runs, 10 loops each)

In [8]: %timeit sample_iter(d, 100)
19.9 ms ? 297 ?s per loop (mean ? std. dev. of 7 runs, 10 loops each)


This was already discussed on python-ideas:
https://mail.python.org/archives/list/python-ideas at python.org/thread/4OZTRD7FLXXZ6R6RU4BME6DYR3AXHOBD/

----------
components: Library (Lib)
messages: 373733
nosy: oscarbenjamin
priority: normal
severity: normal
status: open
title: Add a function to get a random sample from an iterable (reservoir sampling)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Wed Jul 15 21:13:22 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 16 Jul 2020 01:13:22 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1594862002.75.0.190251560034.issue41271@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

See also: https://github.com/python-trio/trio/issues/932 which contains a link to a library with cffi bindings to io_uring

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Wed Jul 15 21:24:31 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 16 Jul 2020 01:24:31 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594862671.02.0.0560077488578.issue41286@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Your best bet then is probably using a library built for this purpose like https://github.com/workhorsy/py-cpuinfo

Like Christian said, exposing this information in the standard library would be a fairly large maintenance burden for a feature that can't really be actioned upon from pure Python code.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Wed Jul 15 21:33:41 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 16 Jul 2020 01:33:41 +0000
Subject: [issue41283] The parameter name for imghdr.what in the documentation
 is wrong
In-Reply-To: <1594545631.96.0.481890798822.issue41283@roundup.psfhosted.org>
Message-ID: <1594863221.83.0.452607984195.issue41283@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
nosy: +ammar2
nosy_count: 2.0 -> 3.0
pull_requests: +20642
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21501

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41283>
_______________________________________

From report at bugs.python.org  Wed Jul 15 22:39:07 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 16 Jul 2020 02:39:07 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1594867147.0.0.569480667271.issue41271@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Wed Jul 15 22:54:01 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 16 Jul 2020 02:54:01 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594868041.43.0.600433810581.issue41299@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> On the smaller scale, it looks quantized to multiples of ~15ms (?), 
> but then it gets more accurate as the times get larger. I don't 
> think it's a measurement error since the first measurement manages
> microseconds.

NT's default system timer resolution for thread dispatching is 15.625 ms. If a wait is for 17 ms, expect to see actual wait times mostly in the range 17 ms up to 31.25 ms. A few outliers may wait longer because the due time on the kernel wait is when the thread is ready to be dispatched, but other threads may preempt it.

The system timer resolution can be increased to about 1 ms (or 500 us with the undocumented NtSetSystemTime system call). But stricter timing still requires combining a dispatcher wait for long course-grained waits with a performance-counter busy wait for short precise waits.

---

But something else is also involved here. I lowered the system timer resolution to 1 ms, and this allowed time.sleep(0.017) to wait for 17-18 ms in about 95% of cases. But the wait for acquiring a _thread.lock stubbornly refused to cooperate. Ultimately it's just calling WaitForSingleObjectEx on a semaphore, so I used ctypes to make a simple alternative lock via CreateSemaphoreW, ReleaseSemaphore, and WaitForSingleObject. This simple implementation performed exactly like the time.sleep wait with regard to the system timer resolution, so the difference is in the _thread.lock wait. I traced it to the following code in EnterNonRecursiveMutex in Python/thread_nt.h:

        /* wait at least until the target */
        ULONGLONG now, target = GetTickCount64() + milliseconds;
        while (mutex->locked) {
            if (PyCOND_TIMEDWAIT(&mutex->cv, &mutex->cs, (long long)milliseconds*1000) < 0) {
                result = WAIT_FAILED;
                break;
            }
            now = GetTickCount64();
            if (target <= now)
                break;
            milliseconds = (DWORD)(target-now);
        }

GetTickCount64 is documented to be "limited to the resolution of the system timer", but what they don't say is that changing the resolution of the system timer has no effect on the minimum increment of the tick count. It still increments by 15-16 ms even if the system timer resolution is set to 1 ms. 

OTOH, the value of QueryInterruptTime [1] and QueryUnbiasedInterruptTime [2] is incremented with the timer interrupt. The biased version [1] is preferred for long waits that may straddle a system sleep or hibernate, but it's only available in Windows 10. I patched EnterNonRecursiveMutex to call QueryInterruptTime instead of GetTickCount64, and this did enable increased precision when waiting on a lock. For example (patched behavior):

    >>> lock = _thread.allocate_lock()
    >>> lock.acquire()
    True
    >>> setup = 'from __main__ import lock'
    >>> stmt = 'lock.acquire(True, 0.017)'

15.625 ms system timer:

    >>> timeit.timeit(stmt, setup, number=1000)
    30.173713599999985

1 ms system timer:

    >>> with set_timer_resolution(0.001):
    ...     timeit.timeit(stmt, setup, number=1000)
    ...
    17.66828049999998

That said, increasing the timer resolution is discouraged in most cases, so  we may simply document that lock waits are limited to the default system timer resolution of 15.625 ms, and increasing the system timer resolution has no effect on this limit.

[1]: https://docs.microsoft.com/en-us/windows/win32/api/realtimeapiset/nf-realtimeapiset-queryinterrupttime
[2]: https://docs.microsoft.com/en-us/windows/win32/api/realtimeapiset/nf-realtimeapiset-queryunbiasedinterrupttime

---

Note that this is unrelated to cancel support via Ctrl+C. Windows Python has no support for canceling a wait on a _thread.lock. It's just a single-object wait in _PyCOND_WAIT_MS, not a multiple-object wait that we set up to include the SIGINT event when called on the main thread (or a variant that I like, which queues a user APC to the main thread for SIGINT instead of using an event, and switches to using alertable waits with SleepEx, WaitForSingleObjectEx, and without needing a wait slot in WaitForMultipleObjectsEx). It's possible to implement a Ctrl+C cancel as long as the lock implementation waits on a kernel semaphore object. However, some effort has gone into developing a different implementation based on condition variables and SRW locks. I don't know whether there's a way to cancel SleepConditionVariableSRW, or whether maybe a different implementation could be used for _thread.lock instead of sharing an implementation with the GIL.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 22:57:53 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 16 Jul 2020 02:57:53 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1594868273.95.0.921287756184.issue41299@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> or 500 us with the undocumented NtSetSystemTime system call

Umm... that should be NtSetTimerResolution. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Wed Jul 15 23:02:07 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Jul 2020 03:02:07 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1594868527.23.0.0584843200866.issue41311@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Wed Jul 15 23:09:33 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 16 Jul 2020 03:09:33 +0000
Subject: [issue40932] subprocess docs should warn of shlex use on Windows
In-Reply-To: <1591735791.89.0.818565720729.issue40932@roundup.psfhosted.org>
Message-ID: <1594868973.49.0.652096632594.issue40932@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
nosy: +ammar2
nosy_count: 7.0 -> 8.0
pull_requests: +20643
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21502

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40932>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:17:41 2020
From: report at bugs.python.org (Charles Machalow)
Date: Thu, 16 Jul 2020 04:17:41 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
Message-ID: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>


New submission from Charles Machalow <csm10495 at gmail.com>:

Right now in str.format(), we have !s, !r, and !a to allow us to call str(), repr(), and ascii() respectively on the given expression.

I'm proposing that we add a !p conversion to have pprint.pformat() be called to convert the given expression to a 'pretty' string.

Calling
```
print(f"My dict: {d!p}")
```

is a lot more concise than:

```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```

We may even be able to have a static attribute stored to change the various default kwargs of pprint.pformat().

----------
components: IO, Library (Lib)
messages: 373738
nosy: Charles Machalow
priority: normal
severity: normal
status: open
title: add !p to pprint.pformat() in str.format() an f-strings
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:23:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Jul 2020 04:23:44 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594873424.71.0.998146221147.issue41312@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This needs discussion on python-ideas/ideas category on discourse similar to f-string debug notation.

----------
nosy: +eric.smith, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:33:16 2020
From: report at bugs.python.org (Alex)
Date: Thu, 16 Jul 2020 04:33:16 +0000
Subject: [issue41278] IDLE: Clarify some completion details in doc
In-Reply-To: <1594451564.07.0.601184325808.issue41278@roundup.psfhosted.org>
Message-ID: <1594873996.34.0.0488340292728.issue41278@roundup.psfhosted.org>


Alex <2423067593 at qq.com> added the comment:

new feature found: 
1.although the name __main__ do not exist even when editing, there will be some completions.
2.if you run a module like this:
def new():
    pass
then create a new module, press __main__. + tab. it will become __main__.new
3.but, if you press __main__._ + tab, the proper list and new will both be shown.
4.the feature 2 & 3 appears even if the first module is closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41278>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:35:44 2020
From: report at bugs.python.org (Charles Machalow)
Date: Thu, 16 Jul 2020 04:35:44 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594874144.62.0.654028354932.issue41312@roundup.psfhosted.org>


Charles Machalow <csm10495 at gmail.com> added the comment:

Fair enough. Didn't really know that list existed. Sent this there. Awaiting moderator approval. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 01:14:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Jul 2020 05:14:49 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1594876489.31.0.633551467749.issue41311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestion.  I'll give it some thought over the next few days.

Here are a few initial thoughts:

* The use of islice() really helps going through a small population quickly.

* The current sample() uses _randbelow() instead of random() to guarantee equidistribution and to eliminate the small biases that come from using random().  So this is a step backwards.

* The current sample() guarantees that slices of the sample are all in randomized order.  The proposed algorithm doesn't:

    # Fully shuffled
    >>> sample(range(20), k=19)
    >>> [3, 19, 11, 16, 5, 12, 10, 7, 14, 0, 6, 18, 8, 9, 4, 13, 15, 2, 1]

    # Not random at all 
    >>> sample_iter(range(20), k=19)
    >>> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 19, 11, 12, 13, 14, 15, 16, 17, 18]

* The current sample runs in speed proportional to *k* rather than *n*.  This means that the proposed algorithm slows down considerably for large populations:

    In [12]: %timeit sample(range(100_000_000), k=20)
    15.7 ?s ? 142 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

    In [13]: %timeit sample_iter(range(100_000_000), k=20)
    1.59 s ? 9.3 ms per loop (mean ? std. dev. of 7 runs, 1 loop each)

* For an apples-to-apples comparison with choices(), use the version in Python 3.9 which was updated to use floor() which is several times faster than int().

* Instead of listing the islice object, consider using next() instead.  That would likely be faster:

    def sample_iter(iterable, k=1):
        iterator = iter(iterable)
        values = list(islice(iterator, k))
        W = exp(log(random())/k)
        try:
            while True:
                # skip is geometrically distributed
                skip = floor( log(random())/log(1-W) )
                values[randrange(k)] = next(islice(iterator, skip, skip+1))
                W *= exp(log(random())/k)
        except StopIteration:
            return values

* Using mock's call-count feature shows that the proposed algorithm uses more entropy that the current sample() code.  It seems that random() and _randbelow() are both being called for every selection.  I haven't yet investigated to what causes this, but it is unfavorable especially for slow generators like SystemRandom().

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Thu Jul 16 01:16:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Jul 2020 05:16:39 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
In-Reply-To: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>
Message-ID: <1594876599.08.0.874126407725.issue41310@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Thu Jul 16 01:57:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Jul 2020 05:57:27 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
In-Reply-To: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>
Message-ID: <1594879047.03.0.117441568596.issue41310@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

CPython is written on C, not C++, so we cannot use std::from_chars.

Note also that to parse a number in JSON we need first to scan the PyUnicode object character-by-character using PyUnicode_READ() which is slower than just reading a byte from a memory, then convert a substring to a nul-terminated bytes string, and finally use the conversion function  which creates a new PyFloat or PyLong objects. The overhead of scanning a string and memory management may be larger than the parsing time itself.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Thu Jul 16 02:00:12 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 16 Jul 2020 06:00:12 +0000
Subject: [issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test
 failures
In-Reply-To: <1593614146.46.0.384684767233.issue41183@roundup.psfhosted.org>
Message-ID: <1594879212.35.0.378310552849.issue41183@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41183>
_______________________________________

From report at bugs.python.org  Thu Jul 16 02:13:12 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 16 Jul 2020 06:13:12 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1594879992.84.0.061758369836.issue31844@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e34bbfd61f405eef89e8aa50672b0b25022de320 by Berker Peksag in branch 'master':
bpo-31844: Remove _markupbase.ParserBase.error() (GH-8562)
https://github.com/python/cpython/commit/e34bbfd61f405eef89e8aa50672b0b25022de320


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Thu Jul 16 02:31:01 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 16 Jul 2020 06:31:01 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1594881061.46.0.442350944137.issue31844@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +20644
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21504

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Thu Jul 16 02:39:05 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 16 Jul 2020 06:39:05 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1594881545.85.0.12119307162.issue31844@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset d4d127f1c6e586036104e4101f5af239fe7dc156 by Berker Peksag in branch 'master':
bpo-31844: Move whatsnew note to 3.10.rst (GH-21504)
https://github.com/python/cpython/commit/d4d127f1c6e586036104e4101f5af239fe7dc156


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Thu Jul 16 02:39:25 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 16 Jul 2020 06:39:25 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1594881565.86.0.593034852368.issue31844@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Thu Jul 16 03:47:19 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 16 Jul 2020 07:47:19 +0000
Subject: [issue41313] OverflowError still raised when int limited in
 sys.maxsize
Message-ID: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Consider this code:
import sys
sys.setrecursionlimit(sys.maxsize)
Causes this:
OverflowError: Python int too large to convert to C int
So what is the limit? It should be sys.maxsize.
These 2 also don't work:
sys.setrecursionlimit(sys.maxsize-1)
sys.setrecursionlimit(sys.maxsize//2)
That is a big difference with at least 50%.

----------
components: C API, Library (Lib)
messages: 373747
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: OverflowError still raised when int limited in sys.maxsize
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 03:52:21 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 16 Jul 2020 07:52:21 +0000
Subject: [issue41313] OverflowError still raised when int limited in
 sys.maxsize
In-Reply-To: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>
Message-ID: <1594885941.63.0.75200996878.issue41313@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Needs to add 10 zeros (sys.maxsize//10000000000) to get it work. //20000000000 doesn't work.
Python version: 3.8.4
Platform: Windows 10 2004

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 03:56:14 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 16 Jul 2020 07:56:14 +0000
Subject: [issue41313] OverflowError still raised when int limited in
 sys.maxsize
In-Reply-To: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>
Message-ID: <1594886174.74.0.0254402808303.issue41313@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Tested. 2**31-31 is the max, which is 2147483617, compared to sys.maxsize's 9223372036854775807!

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 04:00:32 2020
From: report at bugs.python.org (Tony)
Date: Thu, 16 Jul 2020 08:00:32 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594886432.28.0.61670442223.issue41305@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

Ok actually that sounds really important, I am interested.

But to begin doing something like this I need to know what's the general design.

Is it simply combining stream reader and stream writer into a single object and changing the write() function to always wait the write (thus deprecating drain) and that's it?

If there is not more to it I can probably do this pretty quickly, I mean it seems easy on the surface.

If there is more to it then I would like a more thorough explanation. Maybe we should chat about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Thu Jul 16 04:17:57 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Jul 2020 08:17:57 +0000
Subject: [issue41313] OverflowError still raised when int limited in
 sys.maxsize
In-Reply-To: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>
Message-ID: <1594887477.87.0.555612692321.issue41313@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The recursion depth and recursion limit are stored internally as C ints, so yes, 2**31 - 1 = 2147483647 is the maximum value that you can pass to `sys.setrecursionlimit` that won't fail immediately.

But it's unclear why you'd ever want to set the recursion limit that high. What's your goal here? Are you looking for a way to effectively disable that recursion limit altogether? If so, can you explain the use-case?

Note that the recursion limit is there to prevent your code from exhausting the C stack and segfaulting as a result: simply setting that limit to a huge value won't (by itself) allow you to run arbitrarily deeply nested recursions. On my machine, without the protection of the recursion limit, a simple recursive call segfaults at around a depth of 30800.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 05:04:55 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 16 Jul 2020 09:04:55 +0000
Subject: [issue41313] sys.setrecursionlimit: OverflowError still raised when
 int limited in sys.maxsize
In-Reply-To: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>
Message-ID: <1594890295.95.0.941088521947.issue41313@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
title: OverflowError still raised when int limited in sys.maxsize -> sys.setrecursionlimit: OverflowError still raised when int limited in sys.maxsize

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 05:33:15 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 16 Jul 2020 09:33:15 +0000
Subject: [issue40477] Python Launcher app on macOS 10.15 Catalina fails to run
 scripts
In-Reply-To: <1588435279.1.0.0339863635356.issue40477@roundup.psfhosted.org>
Message-ID: <1594891995.55.0.137380199822.issue40477@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40477>
_______________________________________

From report at bugs.python.org  Thu Jul 16 06:12:25 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 16 Jul 2020 10:12:25 +0000
Subject: [issue41249] TypedDict inheritance doesn't work with get_type_hints
 and postponed evaluation of annotations across modules
In-Reply-To: <1594252058.32.0.479050209218.issue41249@roundup.psfhosted.org>
Message-ID: <1594894345.56.0.396461526659.issue41249@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> I was thinking that similarly to __required_keys__ and __optional_keys__, the TypedDict could preserve its original bases in a new dunder attribute, and get_type_hints could work off of that instead of MRO when it is dealing with a TypedDict. I would be willing to contribute the PRs to implement this if the design is acceptable

TBH this is not very elegant, but I think you can go ahead with this (at least as a quick fix) since I don't see a better solution yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41249>
_______________________________________

From report at bugs.python.org  Thu Jul 16 06:34:24 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 16 Jul 2020 10:34:24 +0000
Subject: [issue41314] __future__ doc and PEP 563 conflict
Message-ID: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

In https://docs.python.org/3/library/__future__.html:
annotations | 3.7.0b1 | *4.0* | PEP 563: Postponed evaluation of annotations

In PEP 563:
Starting with Python 3.7, a __future__ import is required to use the described functionality. No warnings are raised.

In Python *3.10* this will become the default behavior. Use of annotations incompatible with this PEP is no longer supported.

Python 4.0 or 3.10? Not clear.

----------
messages: 373753
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: __future__ doc and PEP 563 conflict

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Thu Jul 16 06:34:59 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 16 Jul 2020 10:34:59 +0000
Subject: [issue41314] __future__ doc and PEP 563 conflict
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1594895699.4.0.565206168005.issue41314@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.10, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Thu Jul 16 10:13:33 2020
From: report at bugs.python.org (Jean Abou Samra)
Date: Thu, 16 Jul 2020 14:13:33 +0000
Subject: [issue41315] Add mathematical functions as wrapper to decimal.Decimal
 methods
Message-ID: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>


New submission from Jean Abou Samra <jean at abou-samra.fr>:

Common mathematical functions such as sqrt(), exp(), etc. are available for decimal numbers as methods of decimal.Decimal instances (like https://docs.python.org/3/library/decimal.html#decimal.Decimal.exp). This does not pair well with the math and cmath modules as well as NumPy and SymPy which all define these as functions. It also makes it harder to switch to decimals instead of floats when you realize that your program lacks arithmetic precision.

It would be nice to have functions in the decimal module that called the corresponding methods. This would unify the interface with other modules while keeping backwards compatibility and preserving the possibility to subclass Decimal.

----------
components: Library (Lib)
messages: 373754
nosy: Jean Abou Samra, facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: Add mathematical functions as wrapper to decimal.Decimal methods
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Thu Jul 16 10:14:17 2020
From: report at bugs.python.org (Jean Abou Samra)
Date: Thu, 16 Jul 2020 14:14:17 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1594908857.09.0.860468634945.issue41315@roundup.psfhosted.org>


Change by Jean Abou Samra <jean at abou-samra.fr>:


----------
title: Add mathematical functions as wrapper to decimal.Decimal methods -> Add mathematical functions as wrappers to decimal.Decimal methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Thu Jul 16 11:13:02 2020
From: report at bugs.python.org (Bas Nijholt)
Date: Thu, 16 Jul 2020 15:13:02 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1594912382.83.0.461179096687.issue38856@roundup.psfhosted.org>


Bas Nijholt <basnijholt at gmail.com> added the comment:

I have noticed the following on Linux too:
```
Traceback (most recent call last):
  File "/config/custom_components/kef_custom/aiokef.py", line 327, in _disconnect
    await self._writer.wait_closed()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 323, in wait_closed
    await self._protocol._closed
  File "/config/custom_components/kef_custom/aiokef.py", line 299, in _send_message
    await self._writer.drain()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 339, in drain
    raise exc
  File "/usr/local/lib/python3.7/asyncio/selector_events.py", line 814, in _read_ready__data_received
    data = self._sock.recv(self.max_size)
ConnectionResetError: [Errno 104] Connection reset by peer
```
after which every invocation of `await asyncio.open_connection` fails with `ConnectionRefusedError` until I restart the entire Python process.

IIUC, just ignoring the exception will not be enough.

This issue is about the `ProactorEventLoop` for Windows specifically, however, my process uses the default event loop on Linux.

----------
nosy: +basnijholt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Thu Jul 16 11:41:36 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Thu, 16 Jul 2020 15:41:36 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1594914096.17.0.0298069170289.issue41045@roundup.psfhosted.org>


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


----------
nosy: +amaajemyfren
nosy_count: 5.0 -> 6.0
pull_requests: +20645
pull_request: https://github.com/python/cpython/pull/21509

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Thu Jul 16 13:08:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 16 Jul 2020 17:08:16 +0000
Subject: [issue41304] python 38 embed ignore python38._pth file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1594919296.26.0.49763365034.issue41304@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

For clarity, this was caused by the fix for issue29778, and was only released in 3.8.4 and 3.9.0b4. No other versions had a release before the fix was merged.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Thu Jul 16 13:08:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 16 Jul 2020 17:08:49 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594919329.86.0.273840980659.issue29778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

FYI, issue41304 fixed a regression in this patch in 3.7 and later. The regression shipped in 3.8.4 and 3.9.0b4, but will be fixed in the subsequent releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Thu Jul 16 13:38:35 2020
From: report at bugs.python.org (Chris Meyer)
Date: Thu, 16 Jul 2020 17:38:35 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1594921115.35.0.912726391021.issue38856@roundup.psfhosted.org>


Change by Chris Meyer <cmeyer1969 at gmail.com>:


----------
nosy: +cmeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Thu Jul 16 13:56:36 2020
From: report at bugs.python.org (Keith Blaha)
Date: Thu, 16 Jul 2020 17:56:36 +0000
Subject: [issue41249] TypedDict inheritance doesn't work with get_type_hints
 and postponed evaluation of annotations across modules
In-Reply-To: <1594252058.32.0.479050209218.issue41249@roundup.psfhosted.org>
Message-ID: <1594922196.1.0.278933803266.issue41249@roundup.psfhosted.org>


Keith Blaha <keith.blaha at gmail.com> added the comment:

> TBH this is not very elegant, but I think you can go ahead with this (at least as a quick fix) since I don't see a better solution yet.

Agreed, given that the current workaround of implementing them in the same module works I think I will stick with that while this is brainstormed further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41249>
_______________________________________

From report at bugs.python.org  Thu Jul 16 14:37:23 2020
From: report at bugs.python.org (Artem Bulgakov)
Date: Thu, 16 Jul 2020 18:37:23 +0000
Subject: [issue41316] tarfile: Do not write full path in FNAME field
Message-ID: <1594924643.04.0.7239005729.issue41316@roundup.psfhosted.org>


New submission from Artem Bulgakov <ArtemSBulgakov at ya.ru>:

tarfile sets FNAME field to the path given by user: Lib/tarfile.py:424

It writes full path instead of just basename if user specified absolute path. Some archive viewer apps like 7-Zip may process file incorrectly. Also it creates security issue because anyone can know structure of directories on system and know username or other personal information.

You can reproduce this by running below lines in Python interpreter. Tested on Windows and Linux.

Python 3.8.2 (default, Apr 27 2020, 15:53:34)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import tarfile
>>> open("somefile.txt", "w").write("sometext")
8
>>> tar = tarfile.open("/home/bulgakovas/file.tar.gz", "w|gz")
>>> tar.add("somefile.txt")
>>> tar.close()
>>> open("file.tar.gz", "rb").read()[:50]
b'\x1f\x8b\x08\x08cE\x10_\x02\xff/home/bulgakovas/file.tar\x00\xed\xd3M\n\xc20\x10\x86\xe1\xac=EO\x90'

You can see full path to file.tar (/home/bulgakovas/file.tar) as FNAME field. If you will write just tarfile.open("file.tar.gz", "w|gz"), FNAME will be equal to file.tar.

RFC1952 says about FNAME:
This is the original name of the file being compressed, with any directory components removed.

So tarfile must remove directory names from FNAME and write only basename of file.

----------
components: Library (Lib)
messages: 373759
nosy: ArtemSBulgakov, lars.gustaebel
priority: normal
severity: normal
status: open
title: tarfile: Do not write full path in FNAME field
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/issue41316>
_______________________________________

From report at bugs.python.org  Thu Jul 16 14:42:37 2020
From: report at bugs.python.org (Artem Bulgakov)
Date: Thu, 16 Jul 2020 18:42:37 +0000
Subject: [issue41316] tarfile: Do not write full path in FNAME field
In-Reply-To: <1594924643.04.0.7239005729.issue41316@roundup.psfhosted.org>
Message-ID: <1594924957.05.0.981811712727.issue41316@roundup.psfhosted.org>


Change by Artem Bulgakov <ArtemSBulgakov at ya.ru>:


----------
keywords: +patch
pull_requests: +20646
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21511

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41316>
_______________________________________

From report at bugs.python.org  Thu Jul 16 14:50:06 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Jul 2020 18:50:06 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
In-Reply-To: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>
Message-ID: <1594925406.85.0.458971128544.issue41310@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is there a description of the algorithms or ideas used anywhere? The blog post you link to has no details, and I don't see any useful descriptions in the GitHub README or the source; trawling through the source to figure out what the key ideas are is not ideal. I don't find the tests particularly convincing, either.

I think this is too immature to consider for CPython, right now. Maybe it would make sense to revisit some day in the future if/when the library is more mature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:02:04 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Jul 2020 19:02:04 +0000
Subject: [issue41313] sys.setrecursionlimit: OverflowError still raised when
 int limited in sys.maxsize
In-Reply-To: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>
Message-ID: <1594926124.53.0.428082386279.issue41313@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Setting to pending; I don't see any bug here, and I suspect the original report was based on a misunderstanding of what sys.setrecursionlimit is for.

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:26:17 2020
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 16 Jul 2020 19:26:17 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594927577.63.0.459818892227.issue41286@roundup.psfhosted.org>


Bo?tjan Mejak <bostjan.xperia at gmail.com> added the comment:

Thanks for letting me know about py-cpuinfo. It is a very good tool. It solves my problem. This Python issue can now be closed as "Won't fix".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:41:38 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 16 Jul 2020 19:41:38 +0000
Subject: [issue41286] Built-in platform module does not offer to check for
 processor instructions
In-Reply-To: <1594570524.81.0.0843136035191.issue41286@roundup.psfhosted.org>
Message-ID: <1594928498.47.0.933875085865.issue41286@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Thanks for your understanding Bo?tjan, closing this as requested.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41286>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:48:17 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 16 Jul 2020 19:48:17 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594928897.94.0.757706404306.issue39017@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset cac9ca8ed99bd98f4c0dcd1913a146192bf5ee84 by Petr Viktorin in branch '3.5':
[3.5] bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (#21489)
https://github.com/python/cpython/commit/cac9ca8ed99bd98f4c0dcd1913a146192bf5ee84


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:49:38 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 16 Jul 2020 19:49:38 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1594928978.42.0.750920633532.issue39017@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:49:12 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 16 Jul 2020 19:49:12 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594928952.68.0.817598858439.issue41305@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Is it simply combining stream reader and stream writer into a single object and changing the write() function to always wait the write (thus deprecating drain) and that's it?

Pretty much. We might also rename a few APIs here and there, like "close()" should become an "async def aclose()"

We also will likely want to define a few ABCs.

Which brings me to the most important point: what we need it not coding it (yet), but rather drafting the actual proposal and posting it to https://discuss.python.org/c/async-sig/20.  Once a formal proposal is there we can proceed with the implementation.

It's a bit of a process to follow, but we have to do it this way.

----------
nosy: +aeros, njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Thu Jul 16 15:58:11 2020
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 16 Jul 2020 19:58:11 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594929491.24.0.294132662076.issue41295@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

David, which issue number is this?

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:14:59 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Jul 2020 20:14:59 +0000
Subject: [issue41306] test_tk failure on Arch Linux
In-Reply-To: <1594840353.83.0.567403527611.issue41306@roundup.psfhosted.org>
Message-ID: <1594930499.8.0.78777579135.issue41306@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

What version of Tk is being used?  It's in the output from:
  python3 -m test.pythoninfo
or however you invoke python.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41306>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:33:29 2020
From: report at bugs.python.org (Felix Yan)
Date: Thu, 16 Jul 2020 20:33:29 +0000
Subject: [issue41306] test_tk failure on Arch Linux
In-Reply-To: <1594840353.83.0.567403527611.issue41306@roundup.psfhosted.org>
Message-ID: <1594931609.16.0.733513812577.issue41306@roundup.psfhosted.org>


Felix Yan <felixonmars at archlinux.org> added the comment:

tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.10

It's always reproducible in either a real desktop or Xvfb with arbitrary resolution etc as far as I have tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41306>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:38:02 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 16 Jul 2020 20:38:02 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
In-Reply-To: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>
Message-ID: <1594931882.99.0.755733258795.issue41310@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Gregory, care to take their code and time it against Python?

I'm not inclined to: reading the comments in the code, they're trying "fast paths" already described in papers by Clinger and - later - by Gay.  When those fast paths don't apply, they fall back on the system `strtod`. But Python's current implementation builds on Gay's fastest code (and never falls back to the system).

It's possible they "improved" on Gay by building relatively giant tables of static data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Thu Jul 16 17:00:59 2020
From: report at bugs.python.org (Tony)
Date: Thu, 16 Jul 2020 21:00:59 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594933259.34.0.790751271084.issue41305@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

> Which brings me to the most important point: what we need it not coding it (yet), but rather drafting the actual proposal and posting it to https://discuss.python.org/c/async-sig/20.  Once a formal proposal is there we can proceed with the implementation.

Posted: https://discuss.python.org/t/discussion-on-a-new-api-for-asyncio/4725

By the way I know it's unrelated but I want a CR on https://github.com/python/cpython/pull/21446 I think it's also very important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Thu Jul 16 17:23:42 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 16 Jul 2020 21:23:42 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1594934622.67.0.577315111626.issue41311@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Pro: focus on the "iterable" part of the title. If you want to, e.g., select 3 lines "at random" out of a multi-million-line text file, this kind of reservoir sampling allows to do that holding no more than one line in memory simultaneously. Materializing an iterable in a sequence is sometimes impossible. Yup, it takes O(number of elements) time, but so does anything else that has to look at every element of an iterable (including materializing an iterable in a sequence!).

So this would make most sense as a different function.

Con: over the years we've worked diligently to purge these algorithms of minor biases, leaving them as unbiased as the core generator. Introducing floating-point vagaries goes against that, and results may vary at times due to tiny differences in platform exp() and log() implementations.

Worse, I'm not sure that the _approach_ is beyond reproach: the claim that skips "follow a geometric distribution" is baffling to me. If the reservoir has size K, then when we're looking at the N'th element it should be skipped with probability 1-K/N. But when looking at the N+1'th, that changes to 1-K/(N+1). Then 1-K/(N+2), and so on. These probabilities are all different. In an actual geometric distribution, the skip probability is a constant.

Now 1-K/(N+i) is approximately equal to 1-K/(N+j) for i and j sufficiently close, and for K sufficiently smaller than N, so the skips may be well _approximated_ by a geometric distribution. But that's quite different than saying they _do_ follow a geometric distribution, and I see no reason to trust that the difference can't matter.

The simple algorithm on the Wikipedia page suffers none of these potential problems (it implements an obviously-sound approach, & our `randrange()` is unbiased and platform-independent).  But, for selecting 3 out of a million-element iterable, would invoke the core generator hundreds of thousands of times more often.

----------
nosy: +mark.dickinson, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Thu Jul 16 17:27:19 2020
From: report at bugs.python.org (Tony)
Date: Thu, 16 Jul 2020 21:27:19 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594934839.7.0.836812038712.issue41305@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

By the way if we will eventually combine StreamReader and StreamWriter won't this function (readinto) be useful then?

Maybe we should consider adding it right now.

Tell me your thoughts on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Thu Jul 16 17:34:43 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 16 Jul 2020 21:34:43 +0000
Subject: [issue41305] Add StreamReader.readinto()
In-Reply-To: <1594829804.0.0.326071195505.issue41305@roundup.psfhosted.org>
Message-ID: <1594935283.89.0.518233500454.issue41305@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> By the way if we will eventually combine StreamReader and StreamWriter won't this function (readinto) be useful then?

Yes.  But StreamReader and StreamWriter will stay for the foreseeable future for backwards compatibility pretty much frozen in time.

So I'd like to start treating them as legacy APIs now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41305>
_______________________________________

From report at bugs.python.org  Thu Jul 16 17:56:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jul 2020 21:56:03 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594936563.03.0.868878033102.issue41300@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +20647
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21512

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 17:58:52 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 16 Jul 2020 21:58:52 +0000
Subject: [issue41313] sys.setrecursionlimit: OverflowError still raised when
 int limited in sys.maxsize
In-Reply-To: <1594885639.25.0.559043335267.issue41313@roundup.psfhosted.org>
Message-ID: <1594936732.99.0.365829926469.issue41313@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Mark has already mentioned that setting the recursion limit to a
value higher than 2000-10000 makes no sense.

Apart from that, sys.maxsize is actually documented like this:

   maxsize -- the largest supported length of containers.


So it applies to Py_ssize_t (signed version of size_t), but not to
any C integer in general.

----------
nosy: +skrah
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41313>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:00:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 16 Jul 2020 22:00:57 +0000
Subject: [issue41310] micro-optimization: increase our float parsing speed by
 Nx
In-Reply-To: <1594851715.46.0.792624118962.issue41310@roundup.psfhosted.org>
Message-ID: <1594936857.45.0.873244505152.issue41310@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think we'd want to fall back to strtod, but rather to the code we already use (Gay's). So this would increase our maintenance burden.

I'm also not convinced that we actually spend a lot of time in this code, but of course profiling would be needed to make sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41310>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:02:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jul 2020 22:02:03 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594936923.81.0.245712559316.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

?ukasz, please pull this simple fix to a 3.9.0b4 and 3.8.4 regression into 3.8.5.  It disabled saving files with non-ascii chars.

----------
keywords: +3.8regression -patch
nosy: +lukasz.langa
priority: normal -> release blocker
stage: patch review -> test needed
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:12:05 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 16 Jul 2020 22:12:05 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
Message-ID: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>


New submission from Alex Gr?nholm <alex.gronholm at nextday.fi>:

Unlike with all the other sock_* functions, sock_accept() only removes the reader on the server socket when the socket becomes available for reading (ie. when there's an incoming connection). If the operation is cancelled instead, the reader is not removed.

If then the server socket is closed and a new socket is created which has the same file number and it is used for a socket operation, it will cause a FileNotFoundError because the event loop thinks it has this fd registered but the epoll object does not agree since all closed sockets are automatically removed from it.

The attached script reproduces the problem on Fedora Linux 32 (all relevant Python versions), but not on Windows (on any tested Python versions from 3.6 to 3.8).

----------
components: asyncio
files: bug.py
messages: 373777
nosy: alex.gronholm, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: sock_accept() does not remove server socket reader on cancellation
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49319/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:19:57 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 16 Jul 2020 22:19:57 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1594937997.59.0.909463033714.issue41315@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The top level decimal.py that dispatches to either _decimal or
_pydecimal is pure Python.  So perhaps these applications could
add these methods themselves:


>>> import decimal
>>> def exp(x):
...     return x.exp()
... 
>>> decimal.exp = exp
>>> 
>>> from decimal import *
>>> exp(Decimal(2))
Decimal('7.389056098930650227230427461')


As you see, it is no big deal, but it feels a bit odd to have
some methods like exp() and sqrt() exposed in the top level.


We already have:

  Decimal.exp()

And:

  >>> c = getcontext()
  >>> c.exp(Decimal(2))
  Decimal('7.389056098930650227230427461')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:24:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jul 2020 22:24:56 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594938296.92.0.79656054857.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 38d3864efe914fda64553e2ec75c9ec15574483f by Terry Jan Reedy in branch 'master':
 bpo-41300: IDLE - save files with non-ascii chars  (GH-21512)
https://github.com/python/cpython/commit/38d3864efe914fda64553e2ec75c9ec15574483f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:25:23 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Jul 2020 22:25:23 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594938323.12.0.594901581411.issue41300@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20648
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21513

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:25:31 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Jul 2020 22:25:31 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594938331.2.0.701719597577.issue41300@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20649
pull_request: https://github.com/python/cpython/pull/21514

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:26:49 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Jul 2020 22:26:49 +0000
Subject: [issue41306] test_tk test_widgets.ScaleTest fails with Tk 8.6.10
In-Reply-To: <1594840353.83.0.567403527611.issue41306@roundup.psfhosted.org>
Message-ID: <1594938409.93.0.822943752272.issue41306@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I can reproduce that test failure with Tk 8.6.10 on macOS, along with a few others. I believe various small things have changed in Tk somewhere between 8.6.8 and 8.6.10 in ways that affect some of the Python Tk gui tests, like test_tk and test_ttk_guionly. Some of our tests are pretty brittle with regard to Tk behavior; they captured how a particular version of Tk worked without necessarily a guarantee on the Tk side that the observed behavior wouldn't change. Someone needs to go through and make the tests work with all recent versions of Tk 8.6.x and someone should also get at least some buildbots running with 8.6.10 and really running the gui tests.

----------
nosy: +gpolo, serhiy.storchaka
stage:  -> needs patch
title: test_tk failure on Arch Linux -> test_tk test_widgets.ScaleTest fails with Tk 8.6.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41306>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:37:04 2020
From: report at bugs.python.org (Oscar Benjamin)
Date: Thu, 16 Jul 2020 22:37:04 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1594939024.78.0.0222216370569.issue41311@roundup.psfhosted.org>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

To be clear I suggest that this could be a separate function from the existing sample rather than a replacement or a routine used internally.

The intended use-cases for the separate function are:

1. Select from something where you really do not want to build a list and just want/need to use a single pass. For example in selecting a random line from a text file it is necessary to read the entire file in any case just to know how many lines there are. The method here would mean that you could make the selection in a single pass in O(k) memory. The same can apply to many situations involving generators etc.

2. Convenient, possibly faster selection from a most-likely small dict/set (this was the original context from python-ideas).

The algorithm naturally gives something in between the original order or a randomised order. There are two possibilities for changing that:

a. Call random.shuffle or equivalent either to get the original k items in a random order or at the end before returning.

b. Preserve the original ordering from the iterable: append all new items and use a sentinel for removed items (remove sentinels at the end).

Since randomised order does not come naturally and requires explicit shuffling my preference would be to preserve the original order (b.) because there is no other way to recover the information lost by shuffling (assuming that only a single pass is possible). The user can call shuffle if they want.

To explain what "geometrically distributed" means I need to refer to the precursor algorithm from which this is derived. A simple Python version could be:


def sample_iter_old(iterable, k=1):
    uvals_vals = []
    # Associate a uniform (0, 1) with each element:
    for uval, val in zip(iter(random, None), iterable):
        uvals_vals.append((uval, val))
        uvals_vals.sort()
        uvals_vals = uvals_vals[:k]   # keep the k items with smallest uval
    return [val for uval, val in uvals_vals]


In sample_iter_old each element val of the iterable is associated with a uniform (0, 1) variate uval. At each step we keep the k elements having the smallest uval variates. This is relatively inefficient because we need to generate a uniform variate for each element val of the iterable. Most of the time during the algorithm the new val is simply discarded so sample_iter tries instead to calculate how many items to discard.

The quantity W in sample_iter is the max of the uvals from sample_iter_old:

    W := max(uval, for uval, val in uvals_vals)

A new item from the iterable will be swapped in if its uval is less than W. The number of items skipped before finding a uval < W is geometrically distributed with parameter W.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:42:12 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Jul 2020 22:42:12 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594939332.57.0.591307626196.issue41300@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a7aa280457423b97512810d6d9baac37f99fbf4 by Miss Islington (bot) in branch '3.9':
bpo-41300: IDLE - save files with non-ascii chars  (GH-21512)
https://github.com/python/cpython/commit/5a7aa280457423b97512810d6d9baac37f99fbf4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:47:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jul 2020 22:47:56 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594939676.36.0.307181842858.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ffeb9202540c07d384f82ff3ab86c37c1433283a by Miss Islington (bot) in branch '3.8':
[3.8] bpo-41300: IDLE - save files with non-ascii chars  (GH-21512)
https://github.com/python/cpython/commit/ffeb9202540c07d384f82ff3ab86c37c1433283a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:51:54 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jul 2020 22:51:54 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594939914.07.0.962641788427.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

?ukasz, Please cherry-pick the 3.8 backport,  ffeb920, as it has a 3.8-specific fixup to idlelib/NEWS.txt.

I verified the bug and fix on Windows.  I am leaving this open to add automated tests.

----------
keywords:  -patch
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 16 20:51:15 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 00:51:15 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1594947075.01.0.336514603374.issue41315@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Stefan.  This would mostly be a waste.

Also, the APIs aren't completely harmonious because the Decimal methods accept an optional context object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Thu Jul 16 20:56:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 00:56:11 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594947371.26.0.290812741087.issue41312@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If the python-ideas discussion is fruitful, go ahead and re-open this tracker item.

Personally, I don't see how this would work.  The pretty printing routines rely on knowing their current level of indentation.  Also, much of the "prettiness" comes from making the output span multiple lines, so this wouldn't fit well in the middle of an f-string.  Lastly, the pprint module leaves a lot to be desired and likely needs a rewrite from scratch, so it wouldn't be wise to tie it directly to a core language feature.

----------
nosy: +rhettinger
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:17:19 2020
From: report at bugs.python.org (Charles Machalow)
Date: Fri, 17 Jul 2020 01:17:19 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594948639.25.0.111568671719.issue41312@roundup.psfhosted.org>


Charles Machalow <csm10495 at gmail.com> added the comment:

One of the key things for ppformat here is to format long spanning dicts/lists to multiple lines, that look easy to read in a log. I feel as though that feature/usefulness outweigh potential indentation weirdness.

A lot of the usage would probably be towards the end of an fstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:50:48 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 17 Jul 2020 01:50:48 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594950648.63.0.155695216416.issue41312@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with Raymond that it's unlikely that this will work, as a practical matter. In addition to the other problems mentioned, there's the issue of the many parameters to control pprint.

And I agree with pprint, or a replacement, needing a redesign. I think it should use singledispatch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:54:45 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 17 Jul 2020 01:54:45 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1594950885.4.0.299787885381.issue29778@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I must have taken my stupid pills today.  Why is this considered a "security" "release blocker"?  If you can put files in the root of the hard drive where Windows was installed, surely you have other, easier attack vectors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:55:16 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 17 Jul 2020 01:55:16 +0000
Subject: [issue41316] tarfile: Do not write full path in FNAME field
In-Reply-To: <1594924643.04.0.7239005729.issue41316@roundup.psfhosted.org>
Message-ID: <1594950916.08.0.995016916628.issue41316@roundup.psfhosted.org>


Emmanuel Arias <eamanu at yaerobi.com> added the comment:

Hi,

If I understand correctly, the name that you are using into the tar
is the basename of the file. I didn't test it yet, but this PR will
remove the possibility to create a file into the tar using the
source tree folder?

Maybe we can think about implement a parameter seems like arcname
on Zipfile?

What about that?

Cheers!

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41316>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:58:44 2020
From: report at bugs.python.org (Cameron Simpson)
Date: Fri, 17 Jul 2020 01:58:44 +0000
Subject: [issue40456] Complete adding silent mode for py_compile
In-Reply-To: <1588285530.29.0.122281949999.issue40456@roundup.psfhosted.org>
Message-ID: <1594951124.57.0.908162502334.issue40456@roundup.psfhosted.org>


Cameron Simpson <cs at cskk.id.au> added the comment:

Since bad input causes py_compile.py to issue an error like this:

  File "/usr/local/Cellar/python at 3.8/3.8.3/Frameworks/Python.framework/Versions/3.8/lib/python3.8/py_compile.py", line 213, in main
    if quiet < 2:
NameError: name 'quiet' is not defined

I suggest, to save long review of a larger PR elsewhere, can we please just initially apply a patch like this:

[~/src/cpython(git:py_compile-quiet-not-initialised)]fleet2*> diff
+ exec git diff
diff --git a/Lib/py_compile.py b/Lib/py_compile.py
index 21736896af..cea851274d 100644
--- a/Lib/py_compile.py
+++ b/Lib/py_compile.py
@@ -186,6 +186,7 @@ def main(args=None):
     """
     if args is None:
         args = sys.argv[1:]
+    quiet = 0
     rv = 0
     if args == ['-']:
         while True:

Then the runtime issue goes away, and adding the feature fully can be addressed in a more leisurely fashion.

----------
nosy: +cameron

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40456>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:15:45 2020
From: report at bugs.python.org (Charles Machalow)
Date: Fri, 17 Jul 2020 02:15:45 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594952145.25.0.430509105094.issue41312@roundup.psfhosted.org>


Charles Machalow <csm10495 at gmail.com> added the comment:

In terms of multiple parameters, I propose adding a method to control the defaults used by !p.

Though the defaults would work more than well enough for basic log and print usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:22:56 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 17 Jul 2020 02:22:56 +0000
Subject: [issue41312] add !p to pprint.pformat() in str.format() an f-strings
In-Reply-To: <1594873061.38.0.656587142662.issue41312@roundup.psfhosted.org>
Message-ID: <1594952576.81.0.345079868242.issue41312@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I suggest you discuss this on python-ideas, since we'll need to reach consensus there, first.

----------
components: +Interpreter Core -IO, Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41312>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:40:06 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 17 Jul 2020 02:40:06 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1594953606.32.0.00498944659218.issue41311@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Thanks! That explanation really helps explain where "geometric distribution" comes from. Although why it keeps taking k'th roots remains a mystery to me ;-)

Speaking of which, the two instances of

exp(log(random())/k)

are numerically suspect. Better written as

random()**(1/k)

The underlying `pow()` implementation will, in effect, compute log(random()) with extra bits of precision for internal use. Doing log(random()) forces it to use a 53-bit approximation. Not to mention that it's more _obvious_ to write a k'th root as a k'th root.  Note: then the 1/k can be computed once outside the loop.

Perhaps worse is

log(1-W)

which should be written

log1p(-W)

instead.  W is between 0 and 1, and the closer it is to 0 the more its trailing bits are entirely lost in computing 1-W. It's the purpose of log1p to combat this very problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:14:50 2020
From: report at bugs.python.org (Michael Lazar)
Date: Fri, 17 Jul 2020 03:14:50 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1594955690.16.0.436925432584.issue38656@roundup.psfhosted.org>


Michael Lazar <lazar.michael22 at gmail.com> added the comment:

Greetings,

I just encountered this issue [0] and I agree with the sentiment that the documentation is currently misleading.

Particularly,

> By default, it provides access to the same database as the rest of this module. The initial database is a copy of that provided by the module, and may be extended by loading additional mime.types-style files into the database using the read() or readfp() methods. The mapping dictionaries may also be cleared before loading additional data if the default data is not desired.

?as the rest of the module? implies to me that it should behave the same way as mimetypes.guess_type() does. The documentation only has one other reference to this built-in list of mimetypes, and the default values are hidden behind underscored variable names. I would re-word this as

"By default, it provides access to a database of well-known values defined internally by the python module. Unlike the other mimetypes convenience functions, it does not include definitions from the list of mimetypes.knownfiles. The initial database may be extended by loading additional mime.types-style files into the database using the read() or readfp() methods. The mapping dictionaries may also be cleared before loading additional data if the default data is not desired."

I would be happy to submit a PR if others agree.

[0] https://github.com/michael-lazar/jetforce/issues/38

----------
nosy: +michael-lazar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:41:03 2020
From: report at bugs.python.org (Heyi Tang)
Date: Fri, 17 Jul 2020 03:41:03 +0000
Subject: [issue41318] Better error message of "Cannot recover from stack
 overflow."
Message-ID: <1594957263.52.0.457195944754.issue41318@roundup.psfhosted.org>


New submission from Heyi Tang <tangheyi.09 at gmail.com>:

Is it possible to add more detailed message for the error "Cannot recover from stack overflow"?
Something like "Cannot recover from stack overflow, it may be caused by catching a RecursionError but reaching the limit again before properly handling it."
Maybe the detailed design in https://github.com/python/cpython/blob/master/Include/ceval.h#L48 could also be shown to the developer?

It is hard to understand what happened only with the message "Cannot recover from stack overflow".

I hit the error because I write the code as following:
@some_logger
def f():
    return f()
try:
  f()
except RecursionError:
  print("Recursion Error is raised!")

And it took me a lot of time to figure out why RecursionError is not raised but the "Fatal Python error" is shown.
Finally I realized that the problem is that the following code piece in "some_logger" (Which is an internal library provided by others) caught the exception and make tstate->overflowed=1.

def some_logger(func):
    @functools.wraps(func)
    def new_func(*args, **kwargs):
        try:
            # Unfortunately this code hit RecursionError and catched it
            logger.info(some_message)
        except Exception as e:
            pass # Avoid affecting user function
        return func(*args, **kwargs)
    return new_func

So I think it might be better to provide more information to the developer that "Cannot recover" means that "RecursionError is caught and stack overflow again." and hint user to know the design of _Py_EnterRecursiveCall.

----------
components: Interpreter Core
messages: 373796
nosy: thyyyy
priority: normal
severity: normal
status: open
title: Better error message of "Cannot recover from stack overflow."
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41318>
_______________________________________

From report at bugs.python.org  Fri Jul 17 00:14:29 2020
From: report at bugs.python.org (=?utf-8?b?5a6L5ZiJ6IW+?=)
Date: Fri, 17 Jul 2020 04:14:29 +0000
Subject: [issue41319] IDLE 3.8 can not save and run this file
Message-ID: <1594959269.96.0.591290294869.issue41319@roundup.psfhosted.org>


New submission from ??? <songjt0524 at gmail.com>:

If I delete the chinese in this py file, it can run.
I use notepad and edit it, and it can run derectly in cmd.

----------
assignee: terry.reedy
components: IDLE
files: tempconvert.py
messages: 373797
nosy: terry.reedy, ???
priority: normal
severity: normal
status: open
title: IDLE 3.8 can not save and run this file
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49320/tempconvert.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41319>
_______________________________________

From report at bugs.python.org  Fri Jul 17 01:28:01 2020
From: report at bugs.python.org (Tom Hale)
Date: Fri, 17 Jul 2020 05:28:01 +0000
Subject: [issue41134] distutils.dir_util.copy_tree FileExistsError when
 updating symlinks
In-Reply-To: <1593228362.42.0.387933635808.issue41134@roundup.psfhosted.org>
Message-ID: <1594963681.18.0.183971970895.issue41134@roundup.psfhosted.org>


Change by Tom Hale <tom at hale.ee>:


----------
keywords: +patch
pull_requests: +20651
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41134>
_______________________________________

From report at bugs.python.org  Fri Jul 17 02:47:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jul 2020 06:47:58 +0000
Subject: [issue41316] tarfile: Do not write full path in FNAME field
In-Reply-To: <1594924643.04.0.7239005729.issue41316@roundup.psfhosted.org>
Message-ID: <1594968478.75.0.532340603608.issue41316@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41316>
_______________________________________

From report at bugs.python.org  Fri Jul 17 03:23:42 2020
From: report at bugs.python.org (Artem Bulgakov)
Date: Fri, 17 Jul 2020 07:23:42 +0000
Subject: [issue41316] tarfile: Do not write full path in FNAME field
In-Reply-To: <1594924643.04.0.7239005729.issue41316@roundup.psfhosted.org>
Message-ID: <1594970622.13.0.545109313355.issue41316@roundup.psfhosted.org>


Artem Bulgakov <ArtemSBulgakov at ya.ru> added the comment:

Hi. My PR doesn't remove the possibility to add tree into tar file. It only fixes header for GZIP compression. Any data after this header is not affected.

You can test it by creating two archives with the same data but one with my patch and the second without. All bytes after header are equal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41316>
_______________________________________

From report at bugs.python.org  Fri Jul 17 03:38:23 2020
From: report at bugs.python.org (Kuang-che Wu)
Date: Fri, 17 Jul 2020 07:38:23 +0000
Subject: [issue41320] async process closing after event loop closed
Message-ID: <1594971503.41.0.525176892628.issue41320@roundup.psfhosted.org>


New submission from Kuang-che Wu <kcwu at csie.org>:

(following code is attached as well)
import asyncio
import time

workaround = False

async def slow_proc():
  proc = await asyncio.create_subprocess_exec('sleep', '10', stdout=asyncio.subprocess.PIPE)
  try:
    return await proc.stdout.read()
  except asyncio.CancelledError:
    if workaround:
      proc.terminate()
      time.sleep(0.1)  # hope the machine is not too busy

async def func():
  try:
    return await asyncio.wait_for(slow_proc(), timeout=0.1)
  except asyncio.TimeoutError:
    return 'timeout'

def main():
  while True:
    print('test')
    asyncio.run(func())

main()
------------------------------------
Run above code, it may work without error message (expected behavior).

However, depends on timing, it may show warning/error messages
case 1.
Loop <_UnixSelectorEventLoop running=False closed=True debug=False> that handles pid 1257652 is closed

case 2.
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7fcbcfc66160>
Traceback (most recent call last):
  File "/usr/lib/python3.8/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib/python3.8/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 536, in close
    self._close(None)
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 560, in _close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 719, in call_soon
    self._check_closed()
  File "/usr/lib/python3.8/asyncio/base_events.py", line 508, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
------------------------------------
Although running tasks will be cancelled when asyncio.run is finishing, subprocess' exit handler may be invoked after the event loop is closed.

In above code, I provided a workaround. However it just mitigates the problem and not really fix the root cause.

This is related to https://bugs.python.org/issue35539

p.s. My test environment is Debian 5.5.17

----------
components: asyncio
files: cancel_proc.py
messages: 373799
nosy: asvetlov, kcwu, yselivanov
priority: normal
severity: normal
status: open
title: async process closing after event loop closed
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49321/cancel_proc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41320>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:23:43 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Fri, 17 Jul 2020 08:23:43 +0000
Subject: [issue39959] Bug on multiprocessing.shared_memory
In-Reply-To: <1584128583.89.0.486447704556.issue39959@roundup.psfhosted.org>
Message-ID: <1594974223.36.0.0432792208995.issue39959@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Hi, shared_memory has lot of issues which are mainly being caused due to resource tracking. Initially resource tracking was implemented to keep track of semaphores only, but for some reason resource tracker also started to keep track of shared_memory.
This causes shared memory to be practically useless when used by unrelated processes, because it will be unlinked as soon as a process dies, by processes which are yet to be spawned.

There is already a PR open to fix this https://github.com/python/cpython/pull/15989/files , by applio(a core developer), but for some reason it hasn't been merged yet. I will try to fix the conflicts and request it to be merged.

Now, this will fix most of the issues in shared memory, but still the current implementation of shared memory for linux won't be consistent with windows (which isn't at the moment also). You can read more about the same here: https://bugs.python.org/issue38119#msg352050

----------
nosy: +vinay0410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:28:26 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Fri, 17 Jul 2020 08:28:26 +0000
Subject: [issue39959] Bug on multiprocessing.shared_memory
In-Reply-To: <1584128583.89.0.486447704556.issue39959@roundup.psfhosted.org>
Message-ID: <1594974506.81.0.65773875789.issue39959@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

@rauanargyn , persist flag won't be good idea because it cannot be supported for windows easily, since windows uses a reference counting mechanism to keep track of shared memory and frees it as soon as all the processes using it are done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:30:22 2020
From: report at bugs.python.org (John Belmonte)
Date: Fri, 17 Jul 2020 08:30:22 +0000
Subject: [issue40816] Add missed AsyncContextDecorator to contextlib
In-Reply-To: <1590763993.17.0.319482222949.issue40816@roundup.psfhosted.org>
Message-ID: <1594974622.78.0.362772962756.issue40816@roundup.psfhosted.org>


John Belmonte <john at neggie.net> added the comment:

Thank you heckad!

I'm in need of a decorating asynccontextmanager, and glad that an implementation is in the works that I can copy from in the meantime.

I hope Yuri reviews the PR before long.

----------
nosy: +John Belmonte

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40816>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:31:23 2020
From: report at bugs.python.org (David Caro)
Date: Fri, 17 Jul 2020 08:31:23 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1594974683.54.0.520401202071.issue41295@roundup.psfhosted.org>


David Caro <david at dcaro.es> added the comment:

> David, which issue number is this?

It's issue41295, pr #21473

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:47:49 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Fri, 17 Jul 2020 08:47:49 +0000
Subject: [issue38119] resource tracker destroys shared memory segments when
 other processes should still have valid access
In-Reply-To: <1568217506.85.0.770661201111.issue38119@roundup.psfhosted.org>
Message-ID: <1594975669.12.0.267821615021.issue38119@roundup.psfhosted.org>


Change by Vinay Sharma <vinay0410sharma at gmail.com>:


----------
pull_requests: +20652
pull_request: https://github.com/python/cpython/pull/21516

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38119>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:59:24 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Jul 2020 08:59:24 +0000
Subject: [issue41195] Interface to OpenSSL's security level
In-Reply-To: <1593685697.4.0.691411084209.issue41195@roundup.psfhosted.org>
Message-ID: <1594976364.75.0.497699740287.issue41195@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8e836bb21ce73f0794fd769db5883c29680dfe47 by matthewhughes934 in branch 'master':
bpo-41195: Add getter for Openssl security level (GH-21282)
https://github.com/python/cpython/commit/8e836bb21ce73f0794fd769db5883c29680dfe47


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41195>
_______________________________________

From report at bugs.python.org  Fri Jul 17 05:20:57 2020
From: report at bugs.python.org (dh4931)
Date: Fri, 17 Jul 2020 09:20:57 +0000
Subject: [issue41321] Calculate timestamp is wrong in datetime.datetime
Message-ID: <1594977657.17.0.556958376615.issue41321@roundup.psfhosted.org>


New submission from dh4931 <dh4931 at outlook.com>:

like so
datetime.datetime(1986, 5, 4, 7, 13, 22).timestamp() - datetime.datetime(1986, 5, 4, 0, 0, 0).timestamp()
the result is 22402.0, the result is wrong.
but on May 2nd
datetime.datetime(1986, 5, 2, 7, 13, 22).timestamp() - datetime.datetime(1986, 5, 2, 0, 0, 0).timestamp()
the result is 26002.0, the result is true

----------
components: Extension Modules
messages: 373805
nosy: dh4931
priority: normal
severity: normal
status: open
title: Calculate timestamp is wrong in datetime.datetime
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41321>
_______________________________________

From report at bugs.python.org  Fri Jul 17 05:41:53 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Fri, 17 Jul 2020 09:41:53 +0000
Subject: [issue39584] multiprocessing.shared_memory: MacOS crashes by running
 attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1594978913.74.0.232015836793.issue39584@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Hi, I tried replicating this by truncating normal files but that doesn't crash. The above mentioned call of ftruncate only crashes for when the file descriptor passed points to a shared memory segment.
And only, multiprocessing.shared_memory is currently creating shared_memory using _posixshmem.shm_open.

So, it can be fixed in ftruncate implementation or this can also be handled by multiprocessing.shared_memory.

Please let me know your thoughts about the same.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Fri Jul 17 05:46:57 2020
From: report at bugs.python.org (Alexander Hungenberg)
Date: Fri, 17 Jul 2020 09:46:57 +0000
Subject: [issue41322] unittest: Generator test methods will always be marked
 as passed
Message-ID: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>


New submission from Alexander Hungenberg <alexander.hungenberg at gmail.com>:

The following testcase will always be marked as passed:

from unittest import TestCase

class BuggyTestCase(TestCase):
    def test_generator(self):
        self.assertTrue(False)
        yield None


It happened to us that someone accidentally made the test method a generator function. That error was caught very late, because it always appears to have executed correctly.

Maybe an additional check can be introduced in the unittest module, to check if a test_ method was executed correctly?

----------
components: Library (Lib)
messages: 373807
nosy: defreng
priority: normal
severity: normal
status: open
title: unittest: Generator test methods will always be marked as passed
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Fri Jul 17 05:52:26 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jul 2020 09:52:26 +0000
Subject: [issue41321] Calculate timestamp is wrong in datetime.datetime
In-Reply-To: <1594977657.17.0.556958376615.issue41321@roundup.psfhosted.org>
Message-ID: <1594979546.0.0.899808141197.issue41321@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I cannot reproduce the report on 3.8 and master. Both of the instances return 26002 which is 7 hours, 13 minutes and 22 seconds. Can you please attach a script that I can run to reproduce the difference?

python3
Python 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime(1986, 5, 4, 7, 13, 22).timestamp() - datetime.datetime(1986, 5, 4, 0, 0, 0).timestamp()
26002.0
>>> datetime.datetime(1986, 5, 2, 7, 13, 22).timestamp() - datetime.datetime(1986, 5, 2, 0, 0, 0).timestamp()
26002.0

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41321>
_______________________________________

From report at bugs.python.org  Fri Jul 17 05:52:31 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 17 Jul 2020 09:52:31 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1594979551.99.0.292926687922.issue41297@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I have no opinion on the proposed change.

The "disruption" alex c talks about is that this imports gets seen by modulegraph (and hence pyinstaller and py2app), which will then include doctest and all its dependencies in standalone bundles even though doctest isn't actually used.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:17:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jul 2020 10:17:58 +0000
Subject: [issue41322] unittest: Generator test methods will always be marked
 as passed
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1594981078.76.0.876648437229.issue41322@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://github.com/python/cpython/blob/8e836bb21ce73f0794fd769db5883c29680dfe47/Lib/unittest/case.py#L548 . _callTestMethod just calls the test method and doesn't check for the method to be a generator function to be iterated through. In Python 3.8 the call to test method was separated out as _callTestMethod. So something like below added in the original method should work. I guess there is an existing issue for this.


import unittest
from unittest import TestCase

class BuggyTestCase(TestCase):

    def _callTestMethod(self, method):
        import inspect

        if inspect.isgeneratorfunction(method):
            list(method())
        else:
            method()

    def test_generator(self):
        self.assertTrue(False)
        yield None

if __name__ == "__main__":
    unittest.main()


python3.8 test_foo.py
F
======================================================================
FAIL: test_generator (__main__.BuggyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_foo.py", line 10, in _callTestMethod
    list(method())
  File "test_foo.py", line 15, in test_generator
    self.assertTrue(False)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (failures=1)

----------
nosy: +ezio.melotti, michael.foord, rbcollins, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:27:02 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 17 Jul 2020 10:27:02 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
Message-ID: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Currently we perform various bytecode improvements as a pass on the code objects after generating the code object.

This requires parsing the bytecode to find instructions, recreating the CFG, and rewriting the line number table.

If we perform the optimizations directly on the CFG we can avoid all that additional work.

This would save hundreds of lines of code and avoid coupling the optimization to the line number table format.

----------
assignee: Mark.Shannon
messages: 373811
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Perform "peephole" optimization directly on control-flow graph.
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:38:08 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 17 Jul 2020 10:38:08 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
In-Reply-To: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>
Message-ID: <1594982288.92.0.289775199639.issue41323@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +20653
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21517

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:43:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jul 2020 10:43:52 +0000
Subject: [issue41322] unittest: Generator test methods will always be marked
 as passed
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1594982632.84.0.26813862745.issue41322@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a duplicate of issue15551 and as per discussion in the thread my approach is incoherent with design of unittest to execute generators. I propose closing this as duplicate with same resolution as not fixed unless there is a change required here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:44:27 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 17 Jul 2020 10:44:27 +0000
Subject: [issue40941] Merge generator.gi_running and frame executing flag into
 single frame state
In-Reply-To: <1591795992.13.0.468529987519.issue40941@roundup.psfhosted.org>
Message-ID: <1594982667.66.0.229648717508.issue40941@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset cb9879b948a19c9434316f8ab6aba9c4601a8173 by Mark Shannon in branch 'master':
bpo-40941: Unify implicit and explicit state in the frame and generator objects into a single value. (GH-20803)
https://github.com/python/cpython/commit/cb9879b948a19c9434316f8ab6aba9c4601a8173


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40941>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:52:46 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 10:52:46 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594983166.79.0.576474965037.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Problem also reported on #41319

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:54:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Jul 2020 10:54:03 +0000
Subject: [issue41322] unittest: Generator test methods will always be marked
 as passed
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1594983243.41.0.703537610794.issue41322@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I would raser raise error if the test method returns something suspicious, like generator or coroutine. Or maybe if it returns anything except None.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:54:16 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 17 Jul 2020 10:54:16 +0000
Subject: [issue41241] Unnecessary Type casting in 'if condition'
In-Reply-To: <1594218335.75.0.478641917124.issue41241@roundup.psfhosted.org>
Message-ID: <1594983256.74.0.918095123064.issue41241@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
nosy: +wyz23x2
nosy_count: 3.0 -> 4.0
pull_requests: +20654
pull_request: https://github.com/python/cpython/pull/21518

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41241>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:55:47 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 10:55:47 +0000
Subject: [issue41324] Add a minimal decimal capsule API
Message-ID: <1594983347.35.0.123464083334.issue41324@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a minimal decimal capsule API
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:56:18 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 17 Jul 2020 10:56:18 +0000
Subject: [issue41241] Unnecessary Type casting in 'if condition'
In-Reply-To: <1594218335.75.0.478641917124.issue41241@roundup.psfhosted.org>
Message-ID: <1594983378.95.0.250631189911.issue41241@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests:  -20654

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41241>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:56:48 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 10:56:48 +0000
Subject: [issue41324] Add a minimal decimal capsule API
Message-ID: <1594983408.27.0.261689050649.issue41324@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
keywords: +patch
pull_requests: +20656
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21519

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:56:31 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 17 Jul 2020 10:56:31 +0000
Subject: [issue41241] Unnecessary Type casting in 'if condition'
In-Reply-To: <1594218335.75.0.478641917124.issue41241@roundup.psfhosted.org>
Message-ID: <1594983391.57.0.23804632381.issue41241@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests: +20655
pull_request: https://github.com/python/cpython/pull/21518

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41241>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:01:35 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 17 Jul 2020 11:01:35 +0000
Subject: [issue41319] IDLE 3.8 can not save and run this file
In-Reply-To: <1594959269.96.0.591290294869.issue41319@roundup.psfhosted.org>
Message-ID: <1594983695.01.0.785654684749.issue41319@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
nosy:  -wyz23x2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41319>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:00:25 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 17 Jul 2020 11:00:25 +0000
Subject: [issue41319] IDLE 3.8 can not save and run this file
In-Reply-To: <1594959269.96.0.591290294869.issue41319@roundup.psfhosted.org>
Message-ID: <1594983625.0.0.17010614674.issue41319@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Is bpo-41300 related? It talks about non-ASCII in IDLE.

----------
nosy: +wyz23x2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41319>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:03:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Jul 2020 11:03:24 +0000
Subject: [issue41321] Calculate timestamp is wrong in datetime.datetime
In-Reply-To: <1594977657.17.0.556958376615.issue41321@roundup.psfhosted.org>
Message-ID: <1594983804.4.0.469301553585.issue41321@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It depends on timezone. I guess there was a switch to daylight saving time at that time and place.

----------
nosy: +belopolsky, lemburg, p-ganssle, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41321>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:08:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 11:08:53 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1594984133.37.0.519160987868.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#41319 should be closed as a duplicate, but site will not currently allow me to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:09:41 2020
From: report at bugs.python.org (Tadhg McDonald-Jensen)
Date: Fri, 17 Jul 2020 11:09:41 +0000
Subject: [issue25538] Traceback from __exit__ method is misleading
In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za>
Message-ID: <1594984181.22.0.553838057079.issue25538@roundup.psfhosted.org>


Tadhg McDonald-Jensen <tadhgmister at gmail.com> added the comment:

This is doable, the feature that decides which line is shown in the traceback is the `lnotab` structure in the relevant code object, the structure is described here (https://github.com/python/cpython/blob/3.8/Objects/lnotab_notes.txt) and it supports negative line offsets so it'd be possible to get the with statement closing statements to backup the line numbers to point to the with statement in question.

I have attached a python script which actually achieves this. `correct_with_cleanup_traceback` when passed a function changes the relevant line numbers so the traceback actually point to the with statement when the error is thrown in the __exit__, most of the relevant work is just dealing with the weird format of lnotab.

This is the error thrown by the test script, it has 2 cascading failures in exit so that I could confirm it worked for nested withs and it absolutely points to the relevant with statement as I have highlighted on the traceback,

    Traceback (most recent call last):
      File "/Users/tadhgmcdonald-jensen/Documents/test.py", line 71, in my_test
    >>  with Test(True) as will_fail_first:                             <<<--------- HERE
      File "/Users/tadhgmcdonald-jensen/Documents/test.py", line 67, in __exit__
        raise Exception("error in exit")
    Exception: error in exit

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/Users/tadhgmcdonald-jensen/Documents/test.py", line 78, in <module>
        my_test()
      File "/Users/tadhgmcdonald-jensen/Documents/test.py", line 70, in my_test
    >>  with Test(True) as fail_during_handling:                        <<<--------- HERE 
      File "/Users/tadhgmcdonald-jensen/Documents/test.py", line 67, in __exit__
        raise Exception("error in exit")
    Exception: error in exit

----------
Added file: https://bugs.python.org/file49322/with_traceback_monkeypatch.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25538>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:10:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 11:10:00 +0000
Subject: [issue41319] IDLE 3.8 can not save and run this file
In-Reply-To: <1594959269.96.0.591290294869.issue41319@roundup.psfhosted.org>
Message-ID: <1594984200.23.0.967132048461.issue41319@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: add missing import io in iomenu.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41319>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:10:36 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 11:10:36 +0000
Subject: [issue41319] IDLE 3.8 can not save and run this file
In-Reply-To: <1594959269.96.0.591290294869.issue41319@roundup.psfhosted.org>
Message-ID: <1594984236.78.0.299623369356.issue41319@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Already fixed.  I have asked the fix go in 3.8.5 on Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41319>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:18:33 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 11:18:33 +0000
Subject: [issue41324] Add a minimal decimal capsule API
Message-ID: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

This adds a minimal decimal capsule API.  As can be seen from the patch,
adding anything to decimal while doing it properly is quite labor and
testing intensive, so the intent is to *keep* the API minimal!

That said, some functions are really necessary:

  1) PyDec_TypeCheck()         -- for obvious reasons.

  2) PyDec_Alloc()             -- create new decimals.

  3) PyDec_Get()               -- get the mpd_t, enables the use of all libmpdec functions.

  4) PyDec_AsUint128Triple()   -- export the decimal as (sign, hi, lo, exp).

  5) PyDec_FromUint128Triple() -- create a decimal from (sign, hi, lo, exp).


4) and 5) have been requested by Antoine for a real world use case.  (hi, lo)
is the coefficient as a __uint128_t split in two uint64_t.


Antoine, could you verify that this is sufficient for the database use case?

----------
nosy: +mark.dickinson, pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:20:58 2020
From: report at bugs.python.org (Alexander Hungenberg)
Date: Fri, 17 Jul 2020 11:20:58 +0000
Subject: [issue41322] unittest: Generator test methods will always be marked
 as passed
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1594984858.84.0.529937069753.issue41322@roundup.psfhosted.org>


Alexander Hungenberg <alexander.hungenberg at gmail.com> added the comment:

I would also strongly vote for raising an error if the test method is a generator - not even silently turn it into a list.

It would be straight forward to implement various checks (like the ones you mentioned for generators, coroutines, ...) - and they will absolutely help to prevent unintended errors, especially by more junior developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:24:40 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 11:24:40 +0000
Subject: [issue22194] access to cdecimal / libmpdec API
In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za>
Message-ID: <1594985080.0.0.997218768541.issue22194@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Closing in favor of #41324, which adds just the most important
functions.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add a minimal decimal capsule API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22194>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:25:14 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 11:25:14 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1594985114.49.0.551270563506.issue41324@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:29:28 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 17 Jul 2020 11:29:28 +0000
Subject: [issue41241] Unnecessary Type casting in 'if condition'
In-Reply-To: <1594218335.75.0.478641917124.issue41241@roundup.psfhosted.org>
Message-ID: <1594985368.66.0.98882759913.issue41241@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Wansoo, welcome to Python!


Changes that are purely cosmetic but do not change the underlying meaning of the code are usually refused as they create unwanted code churn. You will find some info about this and all the other aspects of contributing to Python in the Python Dev Guide: https://devguide.python.org/.


If you want to find an issue on which you could work, please have a look at the `easy` `easy (C)` and `newcomer_friendly` issues in the bug tracker. You can find them using the search function of https://bugs.python.org/

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41241>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:36:08 2020
From: report at bugs.python.org (Tadhg McDonald-Jensen)
Date: Fri, 17 Jul 2020 11:36:08 +0000
Subject: [issue25538] Traceback from __exit__ method is misleading
In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za>
Message-ID: <1594985768.02.0.105801731789.issue25538@roundup.psfhosted.org>


Tadhg McDonald-Jensen <tadhgmister at gmail.com> added the comment:

uploaded `with_traceback_fixed+async.py` because I forgot to include async with in my first code.

----------
Added file: https://bugs.python.org/file49323/with_traceback_fixed+async.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25538>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:41:37 2020
From: report at bugs.python.org (Oscar Benjamin)
Date: Fri, 17 Jul 2020 11:41:37 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1594986097.28.0.830565563453.issue41311@roundup.psfhosted.org>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

All good points :)

Here's an implementation with those changes and that shuffles but gives the option to preserve order. It also handles the case W=1.0 which can happen at the first step with probability 1 - (1 - 2**53)**k.

Attempting to preserve order makes the storage requirements expected O(k*log(k)) rather than deterministic O(k) but note that the log(k) part just refers to the values list growing larger with references to None: only k of the items from iterable are stored at any time. This can be simplified by removing the option to preserve order which would also make it faster in the small-iterable case.

There are a few timings below for choosing from a dict vs converting to a list and using sample (I don't have a 3.9 build immediately available to use choices). Note that these benchmarks are not the primary motivation for sample_iter though which is the case where the underlying iterable is much more expensive in memory and/or time and where the length is not known ahead of time.



from math import exp, log, log1p, floor
from random import random, randrange, shuffle as _shuffle
from itertools import islice


def sample_iter(iterable, k=1, shuffle=True):
    """Choose a sample of k items from iterable

    shuffle=True (default) gives the items in random order
    shuffle=False preserves the original ordering of the items
    """
    iterator = iter(iterable)
    values = list(islice(iterator, k))

    irange = range(len(values))
    indices = dict(zip(irange, irange))

    kinv = 1 / k
    W = 1.0
    while True:
        W *= random() ** kinv
        # random() < 1.0 but random() ** kinv might not be
        # W == 1.0 implies "infinite" skips
        if W == 1.0:
            break
        # skip is geometrically distributed with parameter W
        skip = floor( log(random())/log1p(-W) )
        try:
            newval = next(islice(iterator, skip, skip+1))
        except StopIteration:
            break
        # Append new, replace old with dummy, and keep track of order
        remove_index = randrange(k)
        values[indices[remove_index]] = None
        indices[remove_index] = len(values)
        values.append(newval)

    values = [values[indices[i]] for i in irange]

    if shuffle:
        _shuffle(values)

    return values


Timings for a large dict (1,000,000 items):

In [8]: n = 6                                                                                                                                  

In [9]: d = dict(zip(range(10**n), range(10**n)))                                                                                              

In [10]: %timeit sample_iter(d, 10)                                                                                                            
16.1 ms ? 363 ?s per loop (mean ? std. dev. of 7 runs, 100 loops each)

In [11]: %timeit sample(list(d), 10)                                                                                                           
26.3 ms ? 1.88 ms per loop (mean ? std. dev. of 7 runs, 10 loops each)


Timings for a small dict (5 items):

In [14]: d2 = dict(zip(range(5), range(5)))                                                                                                    

In [15]: %timeit sample_iter(d2, 2)                                                                                                            
14.8 ?s ? 539 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

In [16]: %timeit sample(list(d2), 2)                                                                                                           
6.27 ?s ? 457 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)


The crossover point for this benchmark is around 10,000 items with k=2. Profiling at 10,000 items with k=2 shows that in either case the time is dominated by list/next so the time difference is just about how efficiently we can iterate vs build the list. For small dicts it is probably possible to get a significant factor speed up by removing the no shuffle option and simplifying the routine.


> Although why it keeps taking k'th roots remains a mystery to me ;-)

Thinking of sample_iter_old, before doing a swap the uvals in our reservoir look like:

  U0 = {u[1], u[2], ... u[k-1], W0}
  W0 = max(V0)

Here u[1] ... u[k-1] are uniform in (0, W0). We find a new u[n] < W0 which we swap in while removing W0 and afterwards we have

  U1 = {u[1], u[2], ... u[k-1], u[k]}
  W1 = max(U1)

Given that U1 is k iid uniform variates in (0, W0) we have that

  W1 = W0 * max(random() for _ in range(k)) = W0 * W'

Here W' has cdf x**k and so by the inverse sampling method we can generate it as random()**(1/k). That gives the update rule for sample_iter:

  W *= random() ** (1/k)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:57:45 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 11:57:45 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1594987065.35.0.800213741602.issue41324@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Also as a note for Mark and Raymond: This API is for exact conversions
and avoids the use of the context except for raising ConversionSyntax.

I'll add documentation once Antoine has tried it out for his use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 08:16:23 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jul 2020 12:16:23 +0000
Subject: [issue41321] Calculate timestamp is wrong in datetime.datetime
In-Reply-To: <1594977657.17.0.556958376615.issue41321@roundup.psfhosted.org>
Message-ID: <1594988183.91.0.16472635795.issue41321@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Serhiy, you are right. I wrote below script that could explain the difference.

# ../backups/bpo41321.py
import datetime
import zoneinfo

for tz in zoneinfo.available_timezones():
    diff = datetime.datetime(1986, 5, 4, 7, 13, 22, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp() - datetime.datetime(1986, 5, 4, 0, 0, 0, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp()
    if diff != 26002:
        print(diff, tz)

for tz in zoneinfo.available_timezones():
    diff = datetime.datetime(1986, 5, 2, 7, 13, 22, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp() - datetime.datetime(1986, 5, 2, 0, 0, 0, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp()
    if diff != 26002:
        print("Diff using second day", diff, tz)

$ ./python ../backups/bpo41321.py
22402.0 Asia/Harbin
22402.0 Asia/Shanghai
22402.0 PRC
22402.0 Asia/Chongqing
22402.0 Asia/Chungking

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41321>
_______________________________________

From report at bugs.python.org  Fri Jul 17 08:43:58 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 17 Jul 2020 12:43:58 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1594989838.19.0.773901858001.issue41324@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Adding Daniele Varrazzo, in case this is useful for the PostgreSQL
adapter.

----------
nosy: +piro

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:04:21 2020
From: report at bugs.python.org (David K. Hess)
Date: Fri, 17 Jul 2020 13:04:21 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1594991061.04.0.638453544599.issue38656@roundup.psfhosted.org>


David K. Hess <david_k_hess at mac.com> added the comment:

@michael-lazar a documentation change seems the path of least resistance given the complicated history of this module. +1 from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Fri Jul 17 11:04:41 2020
From: report at bugs.python.org (Jean Abou Samra)
Date: Fri, 17 Jul 2020 15:04:41 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1594998281.11.0.393335601085.issue41315@roundup.psfhosted.org>


Jean Abou Samra <jean at abou-samra.fr> added the comment:

I would argue that given a function,

from math import *

def naive_calc_pi(n=100):
    u = sqrt(8)
    v = 4
    for _ in range(n):
        v = 2*u*v/(u + v)
        u = sqrt(u*v)
    return u

when you realize that floats have limited precision (happened to me several times while being taught and teaching Python), you could just replace

from math import *

with

from decimal import *

and use it, instead of the current

from decimal import Decimal as D

def sqrt(x):
    return D(x).sqrt()

Of course, you can define these, but as I repeatedly ended up doing this, I just thought I'd bring the idea upstream.

Another, perhaps more important argument is readability. We all think in terms of functions: log(x), not x.log(). I find it a significant fact that NumPy has both numpy.dot(A, B) and numpy.ndarray.dot(self, B), but the former is generally preferred (the method's documentation points to the function and the first dozen Google search results for "numpy dot product" yield the function). It makes expressions resemble what we are used to: compare

(a + b).tan().log() = (a.tan() + b.tan()).sqrt()/(1 - a.tan()*b.tan()).sqrt()
with
sqrt(tan(a + b)) = sqrt(tan(a) + tan(b))/sqrt(1 - tan(a)*tan(b))

> Also, the APIs aren't completely harmonious because the Decimal methods accept an optional context object.

I don't see a problem with the functions also accepting this parameter. (np.sin() has many parameters after all.)

Overall, I think this modest addition would bring an improvement in the usability of the decimal module. I can make a PR.

----------
nosy: +Jean_Abou_Samra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Fri Jul 17 11:16:56 2020
From: report at bugs.python.org (=?utf-8?q?Vincent_F=C3=A9rotin?=)
Date: Fri, 17 Jul 2020 15:16:56 +0000
Subject: [issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid
 container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
In-Reply-To: <1592488947.97.0.69594351568.issue41024@roundup.psfhosted.org>
Message-ID: <1594999016.86.0.842709679138.issue41024@roundup.psfhosted.org>


Vincent F?rotin <vincent at vincent-ferotin.info> added the comment:

Explicitly add Raymond Hettinger to nosy list, as he reviewed the corresponding PR.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41024>
_______________________________________

From report at bugs.python.org  Fri Jul 17 11:23:42 2020
From: report at bugs.python.org (=?utf-8?q?Vincent_F=C3=A9rotin?=)
Date: Fri, 17 Jul 2020 15:23:42 +0000
Subject: [issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid
 container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
In-Reply-To: <1592488947.97.0.69594351568.issue41024@roundup.psfhosted.org>
Message-ID: <1594999422.43.0.452223078128.issue41024@roundup.psfhosted.org>


Vincent F?rotin <vincent at vincent-ferotin.info> added the comment:

Unless I am mistaken, merged pull-request was not backported from master to other potential branches (3.5 -> 3.9 included). There was a message from GitHub 'miss-islington' bot (https://github.com/python/cpython/pull/20964#issuecomment-646991186) saying, if I understand correctly, to manually cherry-pick merged commit to other branches. Am I correct?
And if so, is there some automatic process for this cherry-picking to re-run, or do someone have to do it manually?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41024>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:22:52 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 17 Jul 2020 16:22:52 +0000
Subject: [issue21625] Make help() beginner helpful when no PAGER or LESS
 variable
In-Reply-To: <1401624278.41.0.968851571107.issue21625@psf.upfronthosting.co.za>
Message-ID: <1595002972.64.0.931434674009.issue21625@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 7.0 -> 8.0
pull_requests: +20657
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21625>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:29:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Jul 2020 16:29:34 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595003374.11.0.373311950217.issue41304@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is now assigned CVE-2020-15801

----------
title: python 38 embed ignore python38._pth file on windows -> [CVE-2020-15801] python 38 embed ignore python38._pth file on windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:34:39 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Jul 2020 16:34:39 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595003679.86.0.374008501242.issue41304@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20658
pull_request: https://github.com/python/cpython/pull/21521

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:47:47 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Jul 2020 16:47:47 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595004467.98.0.0412796546227.issue41304@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20659
pull_request: https://github.com/python/cpython/pull/21522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:48:01 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Jul 2020 16:48:01 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595004481.91.0.585840286958.issue41304@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20661
pull_request: https://github.com/python/cpython/pull/21523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:47:55 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Jul 2020 16:47:55 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595004475.96.0.0837107018983.issue41304@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20660
pull_request: https://github.com/python/cpython/pull/21524

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:54:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Jul 2020 16:54:03 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595004843.53.0.701329310912.issue41304@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a16ac4e43c8ed15bf2fca52df3a0a5de26ad2705 by Miss Islington (bot) in branch '3.9':
bpo-41304: Update NEWS to include CVE-2020-15801 reference (GH-21521)
https://github.com/python/cpython/commit/a16ac4e43c8ed15bf2fca52df3a0a5de26ad2705


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:54:14 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Jul 2020 16:54:14 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595004854.88.0.81155504888.issue41304@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 79ed1a53fa44a1b74e3c24c9d5f698abd9610921 by Miss Islington (bot) in branch '3.8':
bpo-41304: Update NEWS to include CVE-2020-15801 reference (GH-21521)
https://github.com/python/cpython/commit/79ed1a53fa44a1b74e3c24c9d5f698abd9610921


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:10:26 2020
From: report at bugs.python.org (Jordan Speicher)
Date: Fri, 17 Jul 2020 17:10:26 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
Message-ID: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>


New submission from Jordan Speicher <jspiker.6 at gmail.com>:

`args` and `kwargs` were added to unittest `mock.call_args` in https://bugs.python.org/issue21269 however documentation was not updated to state that this was added in python 3.8

----------
assignee: docs at python
components: Documentation
messages: 373839
nosy: docs at python, uspike
priority: normal
severity: normal
status: open
title: Document addition of `mock.call_args.args` and `mock.call_args.kwargs` in 3.8
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:11:22 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 17 Jul 2020 17:11:22 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1595005882.62.0.117003803388.issue39280@roundup.psfhosted.org>


Change by Ram Rachum <ram at rachum.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:29:09 2020
From: report at bugs.python.org (Jordan Speicher)
Date: Fri, 17 Jul 2020 17:29:09 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595006949.17.0.984825116243.issue41325@roundup.psfhosted.org>


Change by Jordan Speicher <jspiker.6 at gmail.com>:


----------
keywords: +patch
pull_requests: +20662
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21525

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:31:49 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 17 Jul 2020 17:31:49 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595007109.0.0.503869150546.issue41317@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

This bug is the same as https://bugs.python.org/issue30064 except for sock_accept().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:43:25 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 17 Jul 2020 17:43:25 +0000
Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on
 email.mime.multipart.MIMEMultipart
In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za>
Message-ID: <1595007805.48.0.187240544906.issue1823@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1823>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:44:12 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 17 Jul 2020 17:44:12 +0000
Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on
 email.mime.multipart.MIMEMultipart
In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za>
Message-ID: <1595007852.79.0.476868828226.issue1823@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I agree with @Victor. I removed the easy tag on this easy

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1823>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:58:05 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Jul 2020 17:58:05 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1595008685.84.0.423087370928.issue41324@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I probably won't try it out explicitly (it's basically cumbersome for us to test with non-release Pythons, because of our dependencies to Numpy and Cython), but reviewing the API should be enough anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Fri Jul 17 14:18:11 2020
From: report at bugs.python.org (Mariatta)
Date: Fri, 17 Jul 2020 18:18:11 +0000
Subject: [issue41326] Build failure in blurb-it repo: "Failed building wheel
 for yarl"
Message-ID: <1595009891.48.0.976644515939.issue41326@roundup.psfhosted.org>


New submission from Mariatta <mariatta at python.org>:

We're seeing travis CI build failure against the nightly Python build v3.10.0a0.

Build log: https://travis-ci.org/github/python/blurb_it/jobs/707532881

Last few lines of the build log:


In file included from /opt/python/3.10-dev/include/python3.10/unicodeobject.h:1026:0,
                   from /opt/python/3.10-dev/include/python3.10/Python.h:97,
                   from yarl/_quoting.c:4:
  /opt/python/3.10-dev/include/python3.10/cpython/unicodeobject.h:551:42: note: declared here
   Py_DEPRECATED(3.3) PyAPI_FUNC(PyObject*) PyUnicode_FromUnicode(
                                            ^
  yarl/_quoting.c: In function ?__Pyx_decode_c_bytes?:
  yarl/_quoting.c:9996:9: warning: ?PyUnicode_FromUnicode? is deprecated [-Wdeprecated-declarations]
           return PyUnicode_FromUnicode(NULL, 0);
           ^
  In file included from /opt/python/3.10-dev/include/python3.10/unicodeobject.h:1026:0,
                   from /opt/python/3.10-dev/include/python3.10/Python.h:97,
                   from yarl/_quoting.c:4:
  /opt/python/3.10-dev/include/python3.10/cpython/unicodeobject.h:551:42: note: declared here
   Py_DEPRECATED(3.3) PyAPI_FUNC(PyObject*) PyUnicode_FromUnicode(
                                            ^
  error: command '/usr/bin/gcc' failed with exit code 1
  ----------------------------------------
  ERROR: Failed building wheel for yarl


I'm not familiar with that part of codebase. If anyone has any insight, it would be appreciated. Thanks.

----------
messages: 373843
nosy: Mariatta
priority: normal
severity: normal
status: open
title: Build failure in blurb-it repo: "Failed building wheel for yarl"
type: compile error
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41326>
_______________________________________

From report at bugs.python.org  Fri Jul 17 14:20:09 2020
From: report at bugs.python.org (Mariatta)
Date: Fri, 17 Jul 2020 18:20:09 +0000
Subject: [issue41326] Build failure in blurb-it repo: "Failed building wheel
 for yarl"
In-Reply-To: <1595009891.48.0.976644515939.issue41326@roundup.psfhosted.org>
Message-ID: <1595010009.34.0.638410874639.issue41326@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Adding Victor Stinner to nosy

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41326>
_______________________________________

From report at bugs.python.org  Fri Jul 17 14:42:52 2020
From: report at bugs.python.org (Paul Moore)
Date: Fri, 17 Jul 2020 18:42:52 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
Message-ID: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>


New submission from Paul Moore <p.f.moore at gmail.com>:

First of all, I do know that this is an issue with the Windows Store distribution, rather than the python.org one. But (a) I don't know where to report a bug against the Store implementation except here, and (b) it's arguably a case of the Windows implementation "stealing" the Python command, so worth flagging against core Python.

The problem is that Windows 10 installs `python` and `python3` executables by default, which open the Windows Store offering to install Python. That's not a bad thing - it's nice to have Python available with the OS! Although (see below) hijacking the `python` and `python3` commands for this purpose has some problems.

But those stubs silently do nothing when run with command line arguments, and because the python.org distribution doesn't put Python on PATH by default, users end up with the stubs available even if they install python.org Python.

We're getting a lot of bug reports from users as a result of this, when they follow standard instructions like "execute `python -m pip`". With the stub on the path, this silently does nothing, even though the user has installed Python. This is a very bad user experience, and not one that projects like pip can do anything to alleviate, other than having extremely convoluted "how to run pip" commands:

"""
To run pip, type `python -m pip` if you're on Unix, and `py -m pip` on Windows. Unless you're using the Windows Store version when you should do `python -m pip` on Windows too. Or on Unix when you might need to do `python3 -m pip`. Or...
"""

I don't have a good answer to this issue. Maybe the Windows Store stubs could detect core Python and do something better if it's installed? Maybe the stubs should print an explanatory message if run with command line arguments? Maybe Store Python should be available on Windows via some less error-prone mechanism?

I'm pretty sure if a Linux distribution shipped a `python` command that didn't run Python the way users expected, there would be complaints. After all, we have PEP 394 that explicitly states how we expect Unix systems to work. Maybe we need something similar for Windows?

----------
assignee: steve.dower
components: Windows
messages: 373845
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Store "stub" Python executables give confusing behaviour
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Fri Jul 17 14:44:13 2020
From: report at bugs.python.org (Paul Moore)
Date: Fri, 17 Jul 2020 18:44:13 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595011453.81.0.874849923041.issue41327@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

See, for example, https://github.com/pypa/packaging-problems/issues/379 as an illustration of the user (and project maintainer!) confusion this causes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Fri Jul 17 14:45:38 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2020 18:45:38 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
In-Reply-To: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>
Message-ID: <1595011538.07.0.695460650566.issue41323@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Fri Jul 17 14:50:03 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2020 18:50:03 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595011803.79.0.474129038503.issue41327@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Closing as "third-party" as those stubs are controlled by Microsoft Windows and has nothing to do with us as a project beyond that they install the Windows Store copy that Steve uploads (although this is all feedback to Steve who has connections on the Windows team).

And I will say I believe there are shims on some Linux distros like Ubuntu for things like venv, pip, etc. which are not included in-box which people typically expect to be there.

----------
nosy: +brett.cannon
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:00:00 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 19:00:00 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
In-Reply-To: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>
Message-ID: <1595012400.65.0.862217437231.issue41323@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 This looks like a nice improvement.  I've long wanted the optimizations to be moved upstream.  

At the time the peephole logic was first written, operating directly on the code object was the only option that kept optimizations separate from the core compiler logic. But disassembling and reassembling bytecode was always awkward ? it is nice to no longer have to do so.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:01:33 2020
From: report at bugs.python.org (Paul Moore)
Date: Fri, 17 Jul 2020 19:01:33 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595012493.17.0.053383317489.issue41327@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

I thought that might be the answer. But does anyone know where I can repost this as an issue against the Store distribution? I'm happy to report there if I can find out how...

Hopefully Steve can point me in the right direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:23:35 2020
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 17 Jul 2020 19:23:35 +0000
Subject: [issue41322] unittest: Generator test methods will always be marked
 as passed
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1595013815.26.0.982704624717.issue41322@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

In the same vein as Serhiy's suggestion, I would like to see unittest raise a DeprecationWarning when a test method returns anything other than `None`, and eventually switch that to an error (probably TypeError or ValueError).

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:33:27 2020
From: report at bugs.python.org (Tzu-ping Chung)
Date: Fri, 17 Jul 2020 19:33:27 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595014407.81.0.951033757413.issue41327@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

FWIW, I tweeted about this a while ago (January) and IIRC Steve said there?s plan to change that. https://twitter.com/uranusjr/status/1212450480917340160

----------
nosy: +uranusjr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:28:36 2020
From: report at bugs.python.org (Dmytro Litvinov)
Date: Fri, 17 Jul 2020 20:28:36 +0000
Subject: [issue41328] Hudson CI is not available anymore
Message-ID: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>


New submission from Dmytro Litvinov <litvinov.dmytro.it at gmail.com>:

In the documentation (https://docs.python.org/3.8/library/unittest.html) there is a mention of Hudson(http://hudson-ci.org/) as continuous integration system for tests. According to wikipedia(https://en.wikipedia.org/wiki/Hudson_(software)), Hudson "Having been replaced by Jenkins, Hudson is no longer maintained[9][10] and was announced as obsolete in February 2017.[11]" 

My recommendation for that is to change the mention of "Hudson" to "Jenkins".

I am ready to prepare PR for that change.

----------
assignee: docs at python
components: Documentation
messages: 373852
nosy: DmytroLitvinov, docs at python
priority: normal
severity: normal
status: open
title: Hudson CI is not available anymore
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:28:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 20:28:48 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595017728.91.0.829399135384.issue41311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Other implementations aren't directly comparable, but I thought I would check to see what others were doing:

* Scikit-learn uses reservoir sampling but only when k / n > 0.99.  Also, it requires a follow-on step to shuffle the selections.

* numpy does not use reservoir sampling.

* Julia's randsubseq() does not use reservoir sampling.  The docs guarantee that, "Complexity is linear in p*length(A), so this function is efficient even if p is small and A is large."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:30:19 2020
From: report at bugs.python.org (Nick.Lupariello)
Date: Fri, 17 Jul 2020 20:30:19 +0000
Subject: [issue41329] IDLE not saving .py files
Message-ID: <1595017819.2.0.254691783518.issue41329@roundup.psfhosted.org>


New submission from Nick.Lupariello <nicklupe13 at gmail.com>:

IDLE will not save .py files. Neither Ctrl + S nor file -> Save file nor file -> Save file as function as intended and the .py file is not updated. 
This happens for both 32 bit and 64 bit distributions on multiple computers with 4 GB of ram running on a AMD A6-9220e RADEON R4. Tested installation in multiple locations. 
IDLE will not write to file anywhere in the file system including documents, desktop, and the installation folder itself.

----------
assignee: terry.reedy
components: IDLE
messages: 373854
nosy: nicklupe13, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE not saving .py files
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41329>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:35:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 20:35:03 +0000
Subject: [issue41319] IDLE 3.8 can not save and run this file
In-Reply-To: <1594959269.96.0.591290294869.issue41319@roundup.psfhosted.org>
Message-ID: <1595018103.37.0.21096040621.issue41319@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

??? put 'import io' at the top of idlelib/iomenu.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41319>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:38:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 20:38:59 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1595018339.4.0.872955166083.issue41297@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ronald, can modulegraph be made smarter with respect to sections of code guarded by __name__ == '__main__'?    That Python idiom is old and pervasive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:58:14 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 17 Jul 2020 20:58:14 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595019494.19.0.995620150454.issue41311@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Julia's randsubseq() doesn't allow to specify the _size_ of the output desired. It picks each input element independently with probability p, and the output can be of any size from 0 through the input's size (with mean output length p*length(A)). Reservoir sampling is simply irrelevant to that, although they almost certainly use a form of skip-generation internally.

The quoted docs don't make much sense: for any given p, O(p*N) = O(N). I'm guessing they're trying to say that the mean of the number of times the RNG is called is p*N.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 18:00:59 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 22:00:59 +0000
Subject: [issue41329] IDLE not saving .py files
In-Reply-To: <1595017819.2.0.254691783518.issue41329@roundup.psfhosted.org>
Message-ID: <1595023259.94.0.739452531039.issue41329@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Add 'import io' to the top of <pythondir>/Lib/idlelib/iomenu.py.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: add missing import io in iomenu.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41329>
_______________________________________

From report at bugs.python.org  Fri Jul 17 18:45:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2020 22:45:05 +0000
Subject: [issue41329] IDLE not saving .py files
In-Reply-To: <1595017819.2.0.254691783518.issue41329@roundup.psfhosted.org>
Message-ID: <1595025905.55.0.681773356321.issue41329@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In calling this a duplicate, and suggesting the fix above, I am assuming that a) you are using the new 3.8.4 and b) you have a non-ascii character in the .py file or files you tested.  Since several years ago, the is the only case of save failing that I know of.  If either is not the case, please reopen and report exact os, python version, minimal file that does not save, and any other possibly relevant details you can think of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41329>
_______________________________________

From report at bugs.python.org  Fri Jul 17 18:53:24 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Jul 2020 22:53:24 +0000
Subject: [issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid
 container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
In-Reply-To: <1592488947.97.0.69594351568.issue41024@roundup.psfhosted.org>
Message-ID: <1595026404.84.0.858559896844.issue41024@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20663
status: pending -> open
pull_request: https://github.com/python/cpython/pull/21527

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41024>
_______________________________________

From report at bugs.python.org  Fri Jul 17 18:55:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 22:55:11 +0000
Subject: [issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid
 container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
In-Reply-To: <1592488947.97.0.69594351568.issue41024@roundup.psfhosted.org>
Message-ID: <1595026511.74.0.484466137414.issue41024@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The backport failed for 3.9.  I'll trigger it again.

Don't see a need to go back to older versions.  This is a minor informational note, not a bug.

----------
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41024>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:34:13 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 23:34:13 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595028853.71.0.628656528921.issue41311@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:34:03 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 23:34:03 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595028843.73.0.0763171261535.issue41311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've put more thought into the proposal and am going to recommend against it.

At its heart, this a CPython optimization to take advantage of list() being slower than a handful of islice() calls.  It also gains a speed benefit by dropping the antibias logic because random() is faster than _randbelow().  IMO, this doesn't warrant an API extension.  I'm not looking forward to years of teaching people that there are two separate APIs for sampling without replacement and that the second one is almost never what they should use.

A few years ago, GvR rejected adding a pre-sizing argument to dicts even though there were some cases where it gave improved performance.  His rationale was that it was challenging for a user to know when they were better off and when they weren't.  It added a new complication that easily led to suboptimal choices. IMO, this new API puts the users in a similar situation.  There are a number of cases where a person is worse off, sometimes much worse off.

This new code runs O(n) instead of O(k).  It eats more entropy. It loses the the antibias protections.  The API makes it less explicit that the entire input iterable is consumed.  It can only be beneficial is the input is not a sequence.  When k gets bigger, the repeated calls to islice() become more expensive than a single call to list.   And given the math library functions involved, I not even sure that this code can guarantee it gives the same results across platforms.

Even if the user makes a correct initial decision about which API to use, the decision can become invalidated when the population sizes or sample sizes change over time.

Lastly, giving users choices between two substantially similar tools typically makes them worse off.  It creates a new burden to learn, remember, and distinguish the two.  It's really nice that we currently have just one sample() and that it behaves well across a broad range of cases ? you generally get a good result without having to think about it.  Presumably, that was the wisdom behind having one-way-to-do-it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:43:06 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 23:43:06 +0000
Subject: [issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid
 container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
In-Reply-To: <1592488947.97.0.69594351568.issue41024@roundup.psfhosted.org>
Message-ID: <1595029386.54.0.760140397873.issue41024@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 760552ceb8c5f5ca4f1bf13f47543b42b25e0b83 by Miss Islington (bot) in branch '3.9':
bpo-41024: doc: Explicitly mention use of 'enum.Enum' as a valid container for '? (GH-20964) (GH-21527)
https://github.com/python/cpython/commit/760552ceb8c5f5ca4f1bf13f47543b42b25e0b83


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41024>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:44:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jul 2020 23:44:23 +0000
Subject: [issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid
 container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
In-Reply-To: <1592488947.97.0.69594351568.issue41024@roundup.psfhosted.org>
Message-ID: <1595029463.85.0.63688885716.issue41024@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41024>
_______________________________________

From report at bugs.python.org  Fri Jul 17 20:09:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2020 00:09:45 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595030985.57.0.938632579905.issue41311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

More thoughts:

* If sample_iter() were added, people would expect a choices_iter() as well.

* Part of the reason that Set support was being dropped from sample() is that it was rarely used and that it was surprising that it was a O(n) operation instead of O(k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 20:21:04 2020
From: report at bugs.python.org (Oscar Benjamin)
Date: Sat, 18 Jul 2020 00:21:04 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595031664.73.0.159150863479.issue41311@roundup.psfhosted.org>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

> At its heart, this a CPython optimization to take advantage of list() being slower than a handful of islice() calls.

This comment suggest that you have missed the general motivation for reservoir sampling. Of course the stdlib can not satisfy all use cases so this can be out of scope as a feature. It is not the case though that this is a CPython optimisation.

The idea of reservoir sampling is that you want to sample from an iterator, you only get one chance to iterate over it, and you don't know a priori how many items it will yield. The classic example of that situation is reading from a text file but in general it maps neatly onto Python's concept of iterators. The motivation for generators/iterators in Python is that there are many situations where it is better to avoid building a concrete in-memory data structure and it can be possible to avoid doing so with appropriately modified algorithms (such as this one). 

The core use case for this feature is not sampling from an in-memory data structure but rather sampling from an expensive generator or an iterator over a file/database. The premise is that it is undesirable or perhaps impossible to build a list out of the items of the iterable. In those contexts the comparative properties of sample/choices are to some extent irrelevant because those APIs can not be used or should be avoided because of their overhead in terms of memory or other resources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Fri Jul 17 20:52:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2020 00:52:37 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1595033557.77.0.126041803107.issue41297@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If not, could modulegraph add a flag to drop imports commonly found in main sections:  doctest, unittest, argparse, etc.?   

Asking the standard library to change seems like the tail wagging the dog ? it only paints over the problem since third-party modules, other standard library modules, and user code commonly use main sections as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:03:30 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 18 Jul 2020 01:03:30 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1595034210.34.0.298835632974.issue41271@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:11:36 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2020 01:11:36 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1595034696.48.0.206362274292.issue41315@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I don't really buy into the use case.  In my experience a nest of existing functions that are designed for floats will somewhere being using a float constant like 0.5, e, pi, or tau.  So, just feeding in a decimal input isn't sufficient to get it to work.  Also, for your idea to work, the function couldn't explicitly reference math.exp(x); instead, it must just use exp() so that you could substitute, "from decimal import exp" for "from math import exp". 

Also, this proposal would be a limited utility because most of the functions in the math module don't have an existing equivalent in the decimal methods.  The inconvenient fact is that the decimal module wasn't designed to be a drop-in substitute for floats ? it's principal design objectives were somewhat different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:43:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jul 2020 01:43:48 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1595036628.54.0.150879732016.issue41271@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think that the answer is maybe, eventually, and if so, an ioring module that any event framework can use and a separate asyncio module for its use with asyncio.  I say maybe because the lwn article suggests that additions and revisions might continue for a decade or more.  A pypi py_iorin wrapper for lib_ioring might need revision with each Linux x.y release for a long time.

The opening question could have been raised on the python-ideas or possibly pydev lists.  Since this list is for patches to cpython, creating and maintaining a py_ioring package on pypi should be discussed elsewhere.  In the meanwhile, this issue could be closed as 'later' ("Issue is to be worked on in a later release cycle.").

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Fri Jul 17 22:11:25 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2020 02:11:25 +0000
Subject: [issue41220] add optional make_key argument to lru_cache
In-Reply-To: <1594054270.54.0.203199023298.issue41220@roundup.psfhosted.org>
Message-ID: <1595038285.05.0.826373568644.issue41220@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've left this open for a week to collect comments.  I concur with Felipe that this should be the responsibility of the caller.  And I concur with Jim that the use cases are likely too rare to warrant shoehorning in the extra functionality.

For my part, I'm concerned that this would be bug bait.  The result of the function would need to be uniquely associated with a particular output, independent of the contents of the mutable arguments.  I don't think it is good design for function calls to be disregarding the part of the input that was originally used to compute the output ? in a way that notion conflict with the core idea of the of the lru_cache giving the same outputs for the same inputs.

Likewise, debugging and exception handing would be complicated by having two underlying user functions.  Exceptions could arise from three sources: the make_key() function, the cached function, and the lru cache internals.

Further, if the make_key() function turns out not to be unique, the ensuring bugs would be hard to find.  In the OP's later example, if we get two distinct inputs which happen to have the same timestamp, the error would pass without warning and would be hard to reproduce.  Similarly, the make_key() function has to assume that the mutable portion of the data hasn't mutated, but a key feature of mutable data is that it can mutate.  That too would result in a hard to find bug.

Also, while the OP has a specific use case in mind, we can't know in advance how others will use make_key().  It could be misused to convert mutable data to immutable data, possibly resulting in a cached function that is slower than the original (caching mean() for example).  Or the make_key() function could had side-effects.  The OP's original "my_list[0]" example showed yet another way that bugs could arise. It is problematic that that particular bug might not have been caught by a test suite that didn't know to call the function twice with a common first argument but with differing subsequent arguments.

Another possible bug trap is that it would make it easier to accidentally cache mutable function results without getting a warning.  For example:
      @lru_cache(128, make_key = lambda target, size, uniq_id, data: uniq_id)
      def search(target, size, uniq_id, data):
           i = data.index(target)
           return data[i : i+size]    # <== bug because this is mutable if data is mutable
       
I think the suggestion was a neat idea (and thought provoking), but I think we should decline because 1) the use case is uncommon 2) because it makes the API harder to understand 3) because it is bug bait and 4) because the responsibility should probably be with the caller.

Thank you for the suggestion.  It was inspired.  Don't be discouraged ? many of my proposals don't get accepted as well.  Please continue to submit suggestions.



P.S. make_key() shouldn't be called a key-function so that we don't make that term ambiguous.  Elsewhere key-functions are all about comparison logic rather than hashing.  They can be created by functools.cmp_to_key(), they tend to be used only once per data element, and the same function tends to be inoperable with all the tools that accept key-functions.  So the term make_key() was likely the better terminology.  Perhaps get_unique_id() would have been even less ambiguous.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41220>
_______________________________________

From report at bugs.python.org  Fri Jul 17 22:53:07 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 18 Jul 2020 02:53:07 +0000
Subject: [issue41314] __future__ doc and PEP 563 conflict
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595040787.47.0.427178770071.issue41314@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Fri Jul 17 23:39:52 2020
From: report at bugs.python.org (Christoph Anton Mitterer)
Date: Sat, 18 Jul 2020 03:39:52 +0000
Subject: [issue29447] Add/check os.PathLike support for the tempfile module's
 'dir' arguments
In-Reply-To: <1486273182.96.0.640027026479.issue29447@psf.upfronthosting.co.za>
Message-ID: <1595043592.13.0.644510212669.issue29447@roundup.psfhosted.org>


Change by Christoph Anton Mitterer <calestyo at scientia.org>:


----------
nosy: +calestyo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29447>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:22:43 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2020 04:22:43 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595046163.89.0.496719771133.issue41311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> This comment suggest that you have missed the general
> motivation for reservoir sampling.

Please don't get personal.  I've devoted a good deal of time thinking about your proposal.  Tim is also giving it an honest look. Please devote some time to honestly thinking about what we have to say.

FWIW, this is an area of expertise for me.  I too have been fascinated with reservoir sampling for several decades, have done a good deal of reading on the topic, and routinely performed statistical sampling as part of my job (where it needed to be done in a legally defensible manner).


> The idea of reservoir sampling is that you want to sample from
> an iterator, you only get one chance to iterate over it, and 
> you don't know a priori how many items it will yield.

Several thoughts:

* The need for sampling a generator or one-time stream of data is in the "almost never" category.  Presumably, that is why you don't find it in numpy or Julia.

* The examples you gave involved dicts or sets.  These aren't one-chance examples and we do know the length in advance.

* Whether talking about sets, dicts, generators, or arbitrary iterators, "sample(list(it), k)" would still work.  Both ways still have to consume the entire input before returning.  So really this is just an optimization, one that under some circumstances runs a bit faster, but one that forgoes a number of desirable characteristics of the existing tool.  

* IMO, sample_iter() is hard to use correctly.  In most cases, the users would be worse off than they are now and it would be challenging to communicate clearly under what circumstances they would be marginally better off.

At any rate, my recommendation stands.  This should not be part of standard library random module API.  Perhaps it could be a recipe or a see-also link.  We really don't have to do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:53:39 2020
From: report at bugs.python.org (Ma Lin)
Date: Sat, 18 Jul 2020 04:53:39 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
Message-ID: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

CJK encode/decode functions only have three error-handler fast-paths:
    replace
    ignore
    strict  
See the code: [1][2]

If use other built-in error-handlers, need to get the error-handler object, and call it with an Unicode Exception argument. See the code: [3]

But the error-handler object is not cached, it needs to be looked up from a dict every time, which is very inefficient.


Another possible optimization is to write fast-path for common error-handlers, Python has these built-in error-handlers:

    strict
    replace
    ignore
    backslashreplace
    xmlcharrefreplace
    namereplace
    surrogateescape
    surrogatepass (only for utf-8/utf-16/utf-32 family)

For example, maybe `xmlcharrefreplace` is heavily used in Web application, it can be implemented as a fast-path, so that no need to call the error-handler object every time.
Just like the `xmlcharrefreplace` fast-path in `PyUnicode_EncodeCharmap` [4].

[1] encode function:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/cjkcodecs/multibytecodec.c#L192

[2] decode function:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/cjkcodecs/multibytecodec.c#L347

[3] `call_error_callback` function:
https://github.com/python/cpython/blob/v3.9.0b4/Modules/cjkcodecs/multibytecodec.c#L82

[4] `xmlcharrefreplace` fast-path in `PyUnicode_EncodeCharmap`:
https://github.com/python/cpython/blob/v3.9.0b4/Objects/unicodeobject.c#L8662

----------
components: Unicode
messages: 373871
nosy: ezio.melotti, malin, vstinner
priority: normal
severity: normal
status: open
title: Inefficient error-handle for CJK encodings
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Sat Jul 18 01:23:52 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jul 2020 05:23:52 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1595049832.51.0.440783864805.issue41282@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Sat Jul 18 01:49:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jul 2020 05:49:26 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595051366.46.0.610108448424.issue41314@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The PEP was accepted apparently by Guido sometime after the second posting 21-Nov-2017.  Guido added the annotations entry to __future__ on 1/26/2018 with the 'mandatory' version changed to 4.0, which means 'some indefinite undecided future version'.  I consider '4.0' to the intentional and definitive until Guido or Lucasz say otherwise.

When PEP implementations differ from the PEP, we do not usually go back and revise the PEP.  The implementation rules unless clearly buggy.

----------
nosy: +gvanrossum, lukasz.langa, terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: __future__ doc and PEP 563 conflict -> PEP 563 and annotations __future__ mandatory version
versions: +Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:14:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jul 2020 06:14:50 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1595052890.4.0.350757351645.issue41315@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Jean, I sympathize a bit with your wish, but decimal was designed for business,  not science.  Sqrt, exp, and 3 versions of log are the only math methods, and they happen to be the ones with some use in business calculations and statistics.  Extended math-science use needs a module that would wrap these methos and either include math module functions or decimal implementations thereof.  This might be candidate for pypi as well as someone's private collection.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:29:19 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jul 2020 06:29:19 +0000
Subject: [issue41322] unittest: deprecate test methods returning non-None
 values
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1595053759.8.0.702449002555.issue41322@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The current behavior is not a bug as it follows documented behavior.  In the absence of any use for returning values from test functions, I agree that we should do the simple thing and raise ValueError (I checked and did not find anything like a UnittestError.) That would add minimal time to testing.

----------
nosy: +terry.reedy
title: unittest: Generator test methods will always be marked as passed -> unittest: deprecate test methods returning non-None values
type: behavior -> enhancement
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:39:42 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 18 Jul 2020 06:39:42 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1595054382.5.0.747514845101.issue39960@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

The problem in the test added in PR 21473 is that there is an intermediate base type "object" in the hierarchy:

    class A(type):
        def __setattr__(cls, key, value):
            type.__setattr__(cls, key, value)

    class B:
        pass

    class C(B, A):
        pass

>>> [c for c in C.__mro__]
[<class '__main__.C'>, <class '__main__.B'>, <class '__main__.A'>, <class 'type'>, <class 'object'>]

>>> [c.__setattr__ for c in C.__mro__]
[<function A.__setattr__ at 0x7f3ca4308378>, <slot wrapper '__setattr__' of 'object' objects>, <function A.__setattr__ at 0x7f3ca4308378>, <slot wrapper '__setattr__' of 'type' objects>, <slot wrapper '__setattr__' of 'object' objects>]

I think the change to the algorithm there is too broad, it disables much of what the check was written for (or against).

Given Guido's second (negative) test case, I think it would also not be correct to add "object.__setattr__" to the list of allowed (intermediate) slot methods:

    class A(type):
        def __setattr__(cls, key, value):
            object.__setattr__(cls, key, value)   # this should fail!

    class B:
        pass

    class C(B, A):
        pass

It's difficult to turn this into an algorithm. Is the MRO really the place to look? For "A", we're only really interested in the C-level bases, aren't we?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39960>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:40:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 06:40:36 +0000
Subject: [issue41322] unittest: deprecate test methods returning non-None
 values
In-Reply-To: <1594979217.32.0.316534480608.issue41322@roundup.psfhosted.org>
Message-ID: <1595054436.16.0.0374037001434.issue41322@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is also a good idea for linters to catch such kind of errors. It will help users of older Python versions.

We cannot raise error without deprecation period or add warnings in old versions because it potentially can break existing code, e.g.:

    def test_ham(self, arg='ham'):
        ...

    def test_spam(self):
        res = test_ham('spam')
        self.assertTrue(res)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41322>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:41:07 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 18 Jul 2020 06:41:07 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1595054467.8.0.833325898852.issue39960@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> intermediate base type "object" in the hierarchy

Sorry, I meant an intermediate base type "B", which inherits its setattr from "object".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39960>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:50:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 06:50:15 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
In-Reply-To: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>
Message-ID: <1595055015.01.0.535200614946.issue41330@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not even sure it was worth to add fast path for "xmlcharrefreplace". "surrogateescape" and "surrogatepass" are most likely used in performance critical cases. It is also easy to add support of "ignore" and "replace". "strict" raises an exception in any case, and "backslashreplace", "xmlcharrefreplace" and "namereplace" are too complex and used in cases when coding time is not dominant (error reporting, debugging, formatting complex documents).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:23:11 2020
From: report at bugs.python.org (Va)
Date: Sat, 18 Jul 2020 07:23:11 +0000
Subject: [issue40059] Provide a toml module in the standard library
In-Reply-To: <1585119261.47.0.818238682424.issue40059@roundup.psfhosted.org>
Message-ID: <1595056991.77.0.575272196604.issue40059@roundup.psfhosted.org>


Va <d.python.dc54 at indigo.re> added the comment:

1.0.0-rc.1 is out by now: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md

----------
nosy: +VA
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40059>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:27:54 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 18 Jul 2020 07:27:54 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1595057274.34.0.123281311611.issue41297@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

modulegraph already knows where the import is done, and users of the library can use that information to make decisions. 

There's no need to make changes to either heapq.py or modulegraph.

For py2app I've made the choice to no be smart about inclusions and just try to include everything that may be imported because disk space is cheap these days.  I just exclude optional dependencies (in py2app, not modulegraph) when I've manually checked that it is safe to do so and the dependency is large.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:37:10 2020
From: report at bugs.python.org (Ma Lin)
Date: Sat, 18 Jul 2020 07:37:10 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
In-Reply-To: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>
Message-ID: <1595057830.13.0.308708077481.issue41330@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

IMO "xmlcharrefreplace" is useful for Web application.

For example, the page's charset is "gbk", then this statement can generate the bytes content easily & safely:

    s.encode('gbk', 'xmlcharrefreplace')

Maybe some HTML-related frameworks use this way to escape characters, such as Sphinx [1].


Attached file `error_handers_fast_paths.txt` summarized all current error-handler fast-paths.

[1] Sphinx use 'xmlcharrefreplace' to escape
https://github.com/sphinx-doc/sphinx/blob/e65021fb9b0286f373f01dc19a5777e5eed49576/sphinx/builders/html/__init__.py#L1029

----------
Added file: https://bugs.python.org/file49324/error_handers_fast_paths.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:45:53 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 18 Jul 2020 07:45:53 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595058353.11.0.110266035389.issue41295@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
pull_requests: +20664
pull_request: https://github.com/python/cpython/pull/21528

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:47:22 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 18 Jul 2020 07:47:22 +0000
Subject: [issue39960] Using typename.__setattr__ in extension type with
 Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
In-Reply-To: <1584138664.49.0.0727456636956.issue39960@roundup.psfhosted.org>
Message-ID: <1595058442.58.0.982547356555.issue39960@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I pushed PR 21528 with a new proposal. See issue 41295.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39960>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:48:17 2020
From: report at bugs.python.org (Jean Abou Samra)
Date: Sat, 18 Jul 2020 07:48:17 +0000
Subject: [issue41315] Add mathematical functions as wrappers to
 decimal.Decimal methods
In-Reply-To: <1594908813.57.0.321710561647.issue41315@roundup.psfhosted.org>
Message-ID: <1595058497.53.0.415622063054.issue41315@roundup.psfhosted.org>


Jean Abou Samra <jean at abou-samra.fr> added the comment:

Okay, understood, thanks for your detailed explanations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41315>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:55:00 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 18 Jul 2020 07:55:00 +0000
Subject: [issue41271] Add support for io_uring to cpython
In-Reply-To: <1594410846.99.0.0025674439126.issue41271@roundup.psfhosted.org>
Message-ID: <1595058900.38.0.423602520114.issue41271@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this as "later" as the consensus is that this might be a useful binding to have, but io_uring is evolving too fast at the moment. 

It is better to develop these bindings on PyPI, which also makes it easier to iterate on the design.

----------
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41271>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:09:04 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 18 Jul 2020 08:09:04 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
In-Reply-To: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>
Message-ID: <1595059744.18.0.340859804132.issue41330@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

But how many new Python web application use CJK codec instead of UTF-8?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:11:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 08:11:25 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595059885.54.0.0377138056189.issue41288@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b4c98ed41e6c959e95b2a6f65c1b728e94039dfd by Serhiy Storchaka in branch 'master':
bpo-41288: Refactor of unpickling NEWOBJ and NEWOBJ_EX opcodes. (GH-21472)
https://github.com/python/cpython/commit/b4c98ed41e6c959e95b2a6f65c1b728e94039dfd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:12:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 08:12:08 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1595059928.44.0.713381934711.issue41262@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 80a50368c0e4dc9d56af0ce748dea35c9d96d23f by Serhiy Storchaka in branch 'master':
bpo-41262: Convert memoryview to Argument Clinic. (GH-21421)
https://github.com/python/cpython/commit/80a50368c0e4dc9d56af0ce748dea35c9d96d23f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:12:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 08:12:58 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1595059978.75.0.565456467769.issue41262@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:26:35 2020
From: report at bugs.python.org (Julien Palard)
Date: Sat, 18 Jul 2020 08:26:35 +0000
Subject: [issue41331] Sphinx can't find asdl.py when not started from the Doc/
 directory
Message-ID: <1595060795.82.0.837754146284.issue41331@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

When running the following command from the Doc/ directory:

    ./venv/bin/sphinx-build -Q -b gettext -D gettext_compact=0 . ../pot/

everything goes right, but when running the following from cpython direcory:

    ./Doc/venv/bin/sphinx-build -Q -b gettext -D gettext_compact=0 Doc pot

we get:

    Extension error:
    Could not import extension asdl_highlight (exception: No module named 'asdl')

This is because sys.path.append(os.path.abspath("../Parser/")) starts from the current directory, cpython/../Parser don't exists while Doc/../Parser exists.

It could be fixed by starting with a Path(__file__).resolve(), will PR it.

----------
assignee: mdk
components: Documentation
messages: 373888
nosy: BTaskaya, mdk
priority: normal
severity: normal
status: open
title: Sphinx can't find asdl.py when not started from the Doc/ directory
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41331>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:31:02 2020
From: report at bugs.python.org (Julien Palard)
Date: Sat, 18 Jul 2020 08:31:02 +0000
Subject: [issue41331] Sphinx can't find asdl.py when not started from the Doc/
 directory
In-Reply-To: <1595060795.82.0.837754146284.issue41331@roundup.psfhosted.org>
Message-ID: <1595061062.71.0.409801394447.issue41331@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
keywords: +patch
pull_requests: +20665
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21529

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41331>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:31:13 2020
From: report at bugs.python.org (Ma Lin)
Date: Sat, 18 Jul 2020 08:31:13 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
In-Reply-To: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>
Message-ID: <1595061073.57.0.418492875334.issue41330@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

> But how many new Python web application use CJK codec instead of UTF-8?

A CJK character usually takes 2-bytes in CJK encodings, but takes 3-bytes in UTF-8.

I tested a Chinese book:
in GBK:     853,025 bytes
in UTF-8: 1,267,523 bytes

For CJK content, UTF-8 is wasteful, maybe CJK encodings will not be eliminated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Sat Jul 18 04:39:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 08:39:08 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
In-Reply-To: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>
Message-ID: <1595061548.39.0.772429576176.issue41330@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In the Web application you need first to generate data (this may involve some network requests, IO operations, and some data transformations), then format the page, then encode it, and finally send it to client. I suppose that the encoding part is minor in comparison with others.

Also, as Inada-san noted, UTF-8 is more popular encoding in modern applications. It is also fast, so you may prefer UTF-8 if the performance of encoding is important to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Sat Jul 18 05:01:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Jul 2020 09:01:05 +0000
Subject: [issue41304] [CVE-2020-15801] python 38 embed ignore python38._pth
 file on windows
In-Reply-To: <1594824077.92.0.734722675541.issue41304@roundup.psfhosted.org>
Message-ID: <1595062865.06.0.902133442325.issue41304@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset eb0d255ffe002412bb937e1bde61225e5431da5e by Miss Islington (bot) in branch '3.7':
bpo-41304: Update NEWS to include CVE-2020-15801 reference (GH-21521) (GH-21524)
https://github.com/python/cpython/commit/eb0d255ffe002412bb937e1bde61225e5431da5e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41304>
_______________________________________

From report at bugs.python.org  Sat Jul 18 05:04:07 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jul 2020 09:04:07 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1595063047.75.0.840088102926.issue41262@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I cannot detect a speedup in test_buffer, which is a heavy user of memoryviews:

# before:
>>> a = [3.742, 3.589, 3.542, 3.495, 3.481, 3.620, 3.773, 3.755, 3.701, 3.661]
>>> sum(a) / 10
3.6358999999999995

# after
>>> b = [3.63, 3.596, 3.475, 3.43, 3.792, 3.58, 3.810, 3.52, 3.55, 3.690]
>>> sum(b) / 10
3.6072999999999995



A microbenchmark shows a speedup:

# before:
$ ./python -m timeit -s "b = b'1234567890'" "memoryview(b)"
2000000 loops, best of 5: 116 nsec per loop

# after:

./python -m timeit -s "b = b'1234567890'" "memoryview(b)"
5000000 loops, best of 5: 98 nsec per loop



As the original author, I'm not sure why I should put up with the
less readable code for such a gain.  For decimal I'm using the pi
benchmark, which, while small, is at least a real math function in
pure Python. 

Do you have other benchmarks?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Sat Jul 18 05:29:48 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Jul 2020 09:29:48 +0000
Subject: [issue41326] Build failure in blurb-it repo: "Failed building wheel
 for yarl"
In-Reply-To: <1595009891.48.0.976644515939.issue41326@roundup.psfhosted.org>
Message-ID: <1595064588.76.0.638408115446.issue41326@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

blurb-it imports aiohttp which imports yarl. It might be a duplicate of https://github.com/aio-libs/yarl/issues/459

----------
nosy: +asvetlov, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41326>
_______________________________________

From report at bugs.python.org  Sat Jul 18 06:34:22 2020
From: report at bugs.python.org (Oscar Benjamin)
Date: Sat, 18 Jul 2020 10:34:22 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595068462.12.0.485580461678.issue41311@roundup.psfhosted.org>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

> Please don't get personal.

Sorry, that didn't come across with the intended tone :)

I agree that this could be out of scope for the random module but I wanted to make sure the reasons were considered.

Reading between the lines I get the impression that you'd both be happier with it if the algorithm was exact (rather than using fp). That would at least give the possibility for it to be used internally by e.g. sample/choice if there was a benefit for some cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Sat Jul 18 07:59:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 11:59:08 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1595073548.18.0.572780225522.issue41262@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not have other benchmarks. memoryview was just one of few builtins which still use PyArg_ParseTupleAndKeywords() and I know how inefficient it is. Since Argument Clinic was already used for memoryview.hex() I did not see problems with converting the rest of memoryview methods to Argument Clinic.

Microbenchmarks:

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "b = b'abcdefgh'" "memoryview(b)"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 187 ns +- 6 ns -> [/home/serhiy/py/cpython-release2/python] 144 ns +- 4 ns: 1.30x faster (-23%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "b = b'abcdefgh'" "memoryview(object=b)"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 312 ns +- 7 ns -> [/home/serhiy/py/cpython-release2/python] 210 ns +- 6 ns: 1.49x faster (-33%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.cast('I')"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 167 ns +- 4 ns -> [/home/serhiy/py/cpython-release2/python] 104 ns +- 2 ns: 1.60x faster (-38%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.cast(format='I')"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 331 ns +- 6 ns -> [/home/serhiy/py/cpython-release2/python] 153 ns +- 7 ns: 2.16x faster (-54%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.cast('B', (2, 2, 2))"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 229 ns +- 5 ns -> [/home/serhiy/py/cpython-release2/python] 154 ns +- 4 ns: 1.48x faster (-32%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.cast(format='B', shape=(2, 2, 2))"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 494 ns +- 11 ns -> [/home/serhiy/py/cpython-release2/python] 198 ns +- 5 ns: 2.49x faster (-60%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.tobytes()"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 90.3 ns +- 3.2 ns -> [/home/serhiy/py/cpython-release2/python] 65.8 ns +- 1.9 ns: 1.37x faster (-27%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.tobytes('C')"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 183 ns +- 6 ns -> [/home/serhiy/py/cpython-release2/python] 129 ns +- 4 ns: 1.41x faster (-29%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release/python -s "m = memoryview(b'abcdefgh')" "m.tobytes(order='C')"
Mean +- std dev: [/home/serhiy/py/cpython-release/python] 340 ns +- 11 ns -> [/home/serhiy/py/cpython-release2/python] 174 ns +- 5 ns: 1.96x faster (-49%)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Sat Jul 18 08:11:43 2020
From: report at bugs.python.org (Riccardo Polignieri)
Date: Sat, 18 Jul 2020 12:11:43 +0000
Subject: [issue38805] locale.getlocale() returns a non RFC1766 language code
In-Reply-To: <1573775129.28.0.0290867966019.issue38805@roundup.psfhosted.org>
Message-ID: <1595074303.32.0.624617993963.issue38805@roundup.psfhosted.org>


Riccardo Polignieri <ric.pol at libero.it> added the comment:

> `locale.getlocale()` is now returning strange results

Not really "strange results" - fact is, now "getlocale()" returns the locale name *as if* it were already set from the beginnning (because it is, at least in part). 

Before: 

>>> import locale  # Python 3.7, new shell
>>> locale.getlocale()
(None, None)
>>> locale.setlocale(locale.LC_ALL, '') # say Hi from Italy
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')

now: 

>>> import locale  # Python 3.8, new shell
>>> locale.getlocale()
('Italian_Italy', '1252')

As for why returned locale names are "a little different" in Windows, I found no better explanation that Eryk Sun's essays in https://bugs.python.org/issue37945. Long story short, it's not even a bug anymore... it's a hot mess and it won't be solved anytime soon. 
But it's not the problem at hand, here. Returned locale names have not changed between 3.7 and 3.8. 



What *is* changed, though, is that now Python on Windows appears to set the locale, implicitly, right from the start. 
Except - maybe it does not, really: 

>>> import locale  # Python 3.8, new shell
>>> locale.getlocale()
('Italian_Italy', '1252')
>>> locale.localeconv()
{'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '', 'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '', 'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127, 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127, 'decimal_point': '.', 'thousands_sep': '', 'grouping': []}

As you can see, we have an Italian locale only in the name: the conventions are still those of the default C locale. 
If we explicitly set the locale, on the other hand... 

>>> locale.setlocale(locale.LC_ALL, '')
'Italian_Italy.1252'
>>> locale.localeconv()
{'int_curr_symbol': 'EUR', 'currency_symbol': '?', ... ... }

... now we enjoy a real Italian locale - pizza, pasta, gelato and all. 



What happened? 
Unfortunately, this change of behaviour is NOT documented, except for a passing note here: https://docs.python.org/3/whatsnew/changelog.html#id144. It's buried *very* deep: 
"""
bpo-34485: On Windows, the LC_CTYPE is now set to the user preferred locale at startup. Previously, the LC_CTYPE locale was ?C? at startup, but changed when calling setlocale(LC_CTYPE, ??) or setlocale(LC_ALL, ??).
"""
This explains... something. Python now pre-sets *only* the LC_CTYPE category, and that's why the other conventions remain unchanged. 
Unfortunately, setting *that* one category changes the result yielded by locale.getlocale(). But this is not a bug either, because it's the same behaviour you would have in Python 3.7: 

>>> locale.setlocale(locale.LC_CTYPE, '')  # Python 3.7
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')

...and that's because locale.getlocale() with no arguments default, wait for it, to getlocale(category=LC_CTYPE), as documented!



So, why Python 3.8 now pre-sets LC_CTYPE on Windows? Apparently, bpo-34485 is part of the ongoing shakespearian feud between Victor Stinner and the Python locale code. If you squint hard enough, you will see the answer here: https://vstinner.github.io/locale-bugfixes-python3.html but at this point, I don't know if anyone still keeps the score. 


To sum up: 
- there's nothing new about locale names - still the same mess; 
- if locale names as returned by locale.getlocale() bother you, you should follow Victor's advice here: https://bugs.python.org/issue37945#msg361806. Use locale.setlocale(category, None) instead; 
- if you relied on getlocale() with no arguments to test your locale, assuming that either a locale is unset or it is "fully set", then you should stop now. A locale can also be "partially set", and in fact it's just what happens now on Windows by default. You should test for a specific category instead; 
- changing the way the locale is set by default on Windows can be... rather surprising and can lead to misunderstandings. I would certainly add a note in the locale documentation to explain this new behaviour.

----------
nosy: +ricpol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38805>
_______________________________________

From report at bugs.python.org  Sat Jul 18 08:32:21 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 18 Jul 2020 12:32:21 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595075541.02.0.0976672459057.issue41295@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

PR 21528 works for all four test cases that we now have (1x test_capi.py, 3x test_descr.py).

Any comments? We need to merge a fix before Monday to meet the deadline of the planned hotfix release.

@kam193, could you please also test that change with your real code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 08:58:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jul 2020 12:58:44 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595077124.41.0.41027076416.issue41325@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a duplicate of https://bugs.python.org/issue40820 . But this PR has cla signed so I am inclined towards merging this instead.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:05:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jul 2020 13:05:47 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595077547.73.0.0524532924463.issue41325@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset 9b01c598ca2576a1056816e85dd84bf5f9c74688 by Jordan Speicher in branch 'master':
bpo-41325: Add version note for args and kwargs property in call object (GH-21525)
https://github.com/python/cpython/commit/9b01c598ca2576a1056816e85dd84bf5f9c74688


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:06:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 13:06:08 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595077567.99.0.672393807111.issue41325@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20666
pull_request: https://github.com/python/cpython/pull/21530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:06:26 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 13:06:26 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595077586.77.0.0643452899465.issue41325@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20667
pull_request: https://github.com/python/cpython/pull/21531

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:08:34 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jul 2020 13:08:34 +0000
Subject: [issue40820] Mock Call attributes args and kwargs have no
 changeversion
In-Reply-To: <1590775441.68.0.287476629705.issue40820@roundup.psfhosted.org>
Message-ID: <1595077714.93.0.329979383506.issue40820@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Closing this in favor of https://bugs.python.org/issue41325

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
superseder:  -> Document addition of `mock.call_args.args` and `mock.call_args.kwargs` in 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40820>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:13:26 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 13:13:26 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595078006.42.0.529949308457.issue41325@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7734738d71c052779d3cb189e5ba0759beb8d620 by Miss Islington (bot) in branch '3.8':
bpo-41325: Add version note for args and kwargs property in call object (GH-21525)
https://github.com/python/cpython/commit/7734738d71c052779d3cb189e5ba0759beb8d620


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:14:35 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 13:14:35 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595078075.46.0.535799198855.issue41325@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f92544483fc724b7e9ac11b2ee86b38e069cc70f by Miss Islington (bot) in branch '3.9':
bpo-41325: Add version note for args and kwargs property in call object (GH-21525)
https://github.com/python/cpython/commit/f92544483fc724b7e9ac11b2ee86b38e069cc70f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:19:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jul 2020 13:19:43 +0000
Subject: [issue41325] Document addition of `mock.call_args.args` and
 `mock.call_args.kwargs` in 3.8
In-Reply-To: <1595005826.72.0.880461567186.issue41325@roundup.psfhosted.org>
Message-ID: <1595078383.17.0.421199311376.issue41325@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Jordan for the report and patch.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41325>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:42:49 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 13:42:49 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595079769.61.0.127685724121.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20668
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:42:52 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 13:42:52 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595079772.13.0.860554267325.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 09:42:54 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 13:42:54 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595079774.14.0.29436267679.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20670
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:18:13 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 18 Jul 2020 14:18:13 +0000
Subject: [issue41332] connect_accepted_socket() missing from AbstractEventLoop
Message-ID: <1595081893.19.0.549157566181.issue41332@roundup.psfhosted.org>


New submission from Alex Gr?nholm <alex.gronholm at nextday.fi>:

The connect_accepted_socket() method seems to be missing from the AbstractEventLoop ABC. I assume this was a simple mistake of omission. I will ready a PR to add it.

----------
components: asyncio
messages: 373904
nosy: alex.gronholm, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: connect_accepted_socket() missing from AbstractEventLoop
type: behavior
versions: 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/issue41332>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:33:06 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 18 Jul 2020 14:33:06 +0000
Subject: [issue41332] connect_accepted_socket() missing from AbstractEventLoop
In-Reply-To: <1595081893.19.0.549157566181.issue41332@roundup.psfhosted.org>
Message-ID: <1595082786.65.0.234457801263.issue41332@roundup.psfhosted.org>


Change by Alex Gr?nholm <alex.gronholm at nextday.fi>:


----------
keywords: +patch
pull_requests: +20671
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21533

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41332>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:33:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 14:33:13 +0000
Subject: [issue41333] Convert OrderedDict.pop() to Argument Clinic
Message-ID: <1595082793.92.0.490500501555.issue41333@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR converts OrderedDict.pop() to Argument Clinic. It makes it 2 times faster.

$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python -s "from collections import OrderedDict; od = OrderedDict()" "od.pop('x', None)"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 119 ns +- 2 ns -> [/home/serhiy/py/cpython-release/python] 56.3 ns +- 1.2 ns: 2.12x faster (-53%)

It was not converted before because Argument Clinic generated incorrect signature for it. It still is not able to generate correct signature, but at least it does not generate incorrect signature. And we now have other reason for using Argument Clinic -- performance.

----------
components: Argument Clinic, Extension Modules
messages: 373905
nosy: larry, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert OrderedDict.pop() to Argument Clinic
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41333>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:34:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 14:34:09 +0000
Subject: [issue41333] Convert OrderedDict.pop() to Argument Clinic
In-Reply-To: <1595082793.92.0.490500501555.issue41333@roundup.psfhosted.org>
Message-ID: <1595082849.71.0.165574518109.issue41333@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20672
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21534

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41333>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:58:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 14:58:51 +0000
Subject: [issue41334] Convert str(), bytes() and bytearray() to Argument Clinic
Message-ID: <1595084331.14.0.93182273048.issue41334@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Constructors str(), bytes() and bytearray() were not converted to Argument Clinic because it was not possible to generate correct signature for them. But now there is other reason of using Argument Clinic -- it generates more efficient code for parsing arguments.

The proposed PR converts str(), bytes() and bytearray() to Argument Clinic but generated docstrings are not used.

$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "str()"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 81.9 ns +- 4.5 ns -> [/home/serhiy/py/cpython-release/python] 60.0 ns +- 1.9 ns: 1.36x faster (-27%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "str('abcdefgh')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 121 ns +- 3 ns -> [/home/serhiy/py/cpython-release/python] 87.6 ns +- 2.8 ns: 1.38x faster (-28%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "str(12345)"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 188 ns +- 8 ns -> [/home/serhiy/py/cpython-release/python] 149 ns +- 5 ns: 1.27x faster (-21%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "str(b'abcdefgh', 'ascii')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 210 ns +- 7 ns -> [/home/serhiy/py/cpython-release/python] 164 ns +- 6 ns: 1.28x faster (-22%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "str(b'abcdefgh', 'ascii', 'strict')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 222 ns +- 9 ns -> [/home/serhiy/py/cpython-release/python] 170 ns +- 6 ns: 1.30x faster (-23%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "str(b'abcdefgh', encoding='ascii', errors='strict')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 488 ns +- 20 ns -> [/home/serhiy/py/cpython-release/python] 306 ns +- 5 ns: 1.59x faster (-37%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytes()"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 85.1 ns +- 2.2 ns -> [/home/serhiy/py/cpython-release/python] 60.2 ns +- 2.3 ns: 1.41x faster (-29%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytes(8)"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 160 ns +- 5 ns -> [/home/serhiy/py/cpython-release/python] 115 ns +- 4 ns: 1.39x faster (-28%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytes(b'abcdefgh')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 131 ns +- 6 ns -> [/home/serhiy/py/cpython-release/python] 91.0 ns +- 2.8 ns: 1.43x faster (-30%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytes('abcdefgh', 'ascii')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 190 ns +- 6 ns -> [/home/serhiy/py/cpython-release/python] 144 ns +- 5 ns: 1.32x faster (-24%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytes('abcdefgh', 'ascii', 'strict')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 214 ns +- 5 ns -> [/home/serhiy/py/cpython-release/python] 156 ns +- 4 ns: 1.37x faster (-27%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytes('abcdefgh', encoding='ascii', errors='strict')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 442 ns +- 9 ns -> [/home/serhiy/py/cpython-release/python] 269 ns +- 8 ns: 1.64x faster (-39%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytearray()"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 93.5 ns +- 2.1 ns -> [/home/serhiy/py/cpython-release/python] 73.1 ns +- 1.8 ns: 1.28x faster (-22%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytearray(8)"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 154 ns +- 3 ns -> [/home/serhiy/py/cpython-release/python] 117 ns +- 3 ns: 1.32x faster (-24%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytearray(b'abcdefgh')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 164 ns +- 5 ns -> [/home/serhiy/py/cpython-release/python] 131 ns +- 2 ns: 1.25x faster (-20%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytearray('abcdefgh', 'ascii')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 239 ns +- 7 ns -> [/home/serhiy/py/cpython-release/python] 193 ns +- 4 ns: 1.24x faster (-19%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytearray('abcdefgh', 'ascii', 'strict')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 260 ns +- 5 ns -> [/home/serhiy/py/cpython-release/python] 207 ns +- 10 ns: 1.26x faster (-21%)
$ ./python -m pyperf timeit -q --compare-to=../cpython-release2/python "bytearray('abcdefgh', encoding='ascii', errors='strict')"
Mean +- std dev: [/home/serhiy/py/cpython-release2/python] 505 ns +- 11 ns -> [/home/serhiy/py/cpython-release/python] 322 ns +- 7 ns: 1.57x faster (-36%)

----------
components: Argument Clinic, Installation, Unicode
messages: 373906
nosy: ezio.melotti, larry, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Convert str(), bytes() and bytearray() to Argument Clinic
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41334>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:04:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jul 2020 15:04:33 +0000
Subject: [issue41334] Convert str(), bytes() and bytearray() to Argument Clinic
In-Reply-To: <1595084331.14.0.93182273048.issue41334@roundup.psfhosted.org>
Message-ID: <1595084673.75.0.526065222867.issue41334@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20673
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21535

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41334>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:06:12 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jul 2020 15:06:12 +0000
Subject: [issue41334] Convert str(), bytes() and bytearray() to Argument Clinic
In-Reply-To: <1595084331.14.0.93182273048.issue41334@roundup.psfhosted.org>
Message-ID: <1595084772.59.0.384753658697.issue41334@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41334>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:13:11 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 18 Jul 2020 15:13:11 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595085191.66.0.816734271014.issue41314@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The PEP now says 3.10, so the docs for __future__ should be fixed.

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:58:14 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 15:58:14 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595087894.59.0.172334648807.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20674
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:58:27 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 15:58:27 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595087907.81.0.353255809054.issue39093@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

It appears there are issues with this issue and so the PR for it is https://github.com/python/cpython/pull/21532

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:47:21 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 16:47:21 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595090841.9.0.606589591829.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20675
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:49:12 2020
From: report at bugs.python.org (Nagarajan)
Date: Sat, 18 Jul 2020 16:49:12 +0000
Subject: [issue21625] Make help() beginner helpful when no PAGER or LESS
 variable
In-Reply-To: <1401624278.41.0.968851571107.issue21625@psf.upfronthosting.co.za>
Message-ID: <1595090952.79.0.299802787256.issue21625@roundup.psfhosted.org>


Nagarajan <nag.rajan at gmail.com> added the comment:

I would request us to think about a couple more options while this is under consideration...

Do we want to also add the flags -X and -F to the less options?

The -X flag gets less to show its output inline, instead of a separate screen. The advantage here is that users can now see the last viewed help page right above the prompt even after quitting help. It helps immensely to be able to see the help and write statements based on the help. The minor downside is that the last statements typed on the python prompt have now scrolled farther up.

The -F (or --quit-if-one-screen) flag exits helps automatically if the help contents fit less than one screen-full. This is only useful when used in conjunction with the -X flag. If we do decide to use the -X flag, then this flag becomes an obvious choice.

If we do choose to use these flags, the less command now becomes

    less "-P?e(END) .(q to exit help) " -X --quit-if-one-screen --quit-at-eof

----------
nosy: +nagarajan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21625>
_______________________________________

From report at bugs.python.org  Sat Jul 18 13:03:19 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 17:03:19 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595091799.38.0.794702013339.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20676
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 13:06:01 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 18 Jul 2020 17:06:01 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595091961.13.0.276536536183.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20677
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sat Jul 18 13:28:43 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jul 2020 17:28:43 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1595093323.29.0.00420878579236.issue41324@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

It looks like the API would be usable, so the PR now has documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Sat Jul 18 14:38:22 2020
From: report at bugs.python.org (Howard A. Landman)
Date: Sat, 18 Jul 2020 18:38:22 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
Message-ID: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>


New submission from Howard A. Landman <howard at riverrock.org>:

I have a program qtd.py that reliably dies with free(): invalid pointer after about 13 hours of runtime (on a RPi3B+). This is hard to debug because (1) try:except: will not catch SIGABRT
(2) signal.signal(signal.SIGABRT, sigabrt_handler) also fails to catch SIGABRT
(3) python3-dbg does not work with libraries like RPi.GPIO and spidev()
This happens under both Buster and Stretch, so I don't think it's OS-dependent.

I managed to get a core dump and gdb back trace gives:
warning: core file may not match specified executable file.
[New LWP 10277]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `python3 qtd.py'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76c5e308 in __GI_abort () at abort.c:100
#2  0x76cae51c in __libc_message (action=action at entry=do_abort, 
    fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181
#3  0x76cb5044 in malloc_printerr (str=<optimized out>) at malloc.c:5341
#4  0x76cb6d50 in _int_free (av=0x76d917d4 <main_arena>, 
    p=0x43417c <small_ints.lto_priv+72>, have_lock=<optimized out>)
    at malloc.c:4165
#5  0x001b3bb4 in list_ass_item (a=<optimized out>, i=<optimized out>, 
    v=<optimized out>, a=<optimized out>, i=<optimized out>, v=<optimized out>)
    at ../Objects/listobject.c:739
Backtrace stopped: Cannot access memory at address 0x17abeff8

So, as far as I can tell, it looks like list_ass_item() is where the error happens. I'm willing to help debug and maybe even fix this, but is there any way to remove any of the roadblocks (1-3) above?

NOTE: qtd.py will exit unless there is a Texas Instruments TDC7201 chip attached to the RPI's SPI pins.

----------
components: Interpreter Core
hgrepos: 389
messages: 373911
nosy: Howard_Landman
priority: normal
severity: normal
status: open
title: free(): invalid pointer in list_ass_item() in Python 3.7.3
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Sat Jul 18 15:04:44 2020
From: report at bugs.python.org (Howard A. Landman)
Date: Sat, 18 Jul 2020 19:04:44 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595099084.99.0.134746826591.issue41335@roundup.psfhosted.org>


Change by Howard A. Landman <howard at riverrock.org>:


----------
hgrepos:  -389

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Sat Jul 18 15:05:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jul 2020 19:05:41 +0000
Subject: [issue41336] Random segfaults during zoneinfo object creation stopped
 using Ctrl-C
Message-ID: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I get segfaults on random basis in the below program I wrote for issue41321 while trying to use Ctrl-C to stop the program. I used faulthandler but couldn't get to the exact case where it occurs. I tested it on Python 3.9 from deadsnakes ppa and it crashes. I tried using gdb to get a backtrace but using ctrl-C is caught by gdb. I tried using "handle SIGINT noprint pass" to ensure the ctrl-C is passed to the program by gdb and attached below is a backtrace during a sample segfault. I am wording it as during zoneinfo creation but isolated object creation under an infinite loop where ctrl-c is passed doesn't trigger this. Feel free to modify this as needed and also to add more since I am not good with debugging C issues.

import datetime
import zoneinfo

timezones = zoneinfo.available_timezones()
for year in range(1900, 2020):
    for tz in timezones:
        d1 = datetime.datetime(year, 5, 4, 7, 13, 22, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp()
        d2 = datetime.datetime(year, 5, 4, 0, 0, 0, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp()
        diff = d1 - d2
        if diff != 26002:
            print(year, diff, tz)

    for tz in timezones:
        d1 = datetime.datetime(year, 5, 2, 7, 13, 22, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp()
        d2 = datetime.datetime(year, 5, 2, 0, 0, 0, tzinfo=zoneinfo.ZoneInfo(tz)).timestamp()
        diff = d1 - d2
        if diff != 26002:
            print("Diff using second day", year, diff, tz)

$ python3.9 -X faulthandler ../backups/bpo41321.py
^CFatal Python error: Segmentation fault

Current thread 0x00007f23bb2b9740 (most recent call first):
  File "/root/cpython/../backups/bpo41321.py", line 7 in <module>
[1]    1234 segmentation fault (core dumped)  python3.9 -X faulthandler ../backups/bpo41321.py

Debug build on master branch

$  ./python -X faulthandler ../backups/bpo41321.py
^Cpython: Objects/typeobject.c:3244: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.
Fatal Python error: Aborted

Current thread 0x00007f28c2256080 (most recent call first):
  File "/root/cpython/../backups/bpo41321.py", line 14 in <module>
[1]    1386 abort (core dumped)  ./python -X faulthandler ../backups/bpo41321.py


(gdb) r
Starting program: /root/cpython/python ../backups/bpo41321.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^C
Program received signal SIGSEGV, Segmentation fault.
zoneinfo_no_cache (cls=<optimized out>, args=<optimized out>, 
    kwargs=<optimized out>) at /root/cpython/Modules/_zoneinfo.c:380
380	    PyObject *out = zoneinfo_new_instance(cls, key);
(gdb) bt
#0  zoneinfo_no_cache (cls=<optimized out>, args=<optimized out>, 
    kwargs=<optimized out>) at /root/cpython/Modules/_zoneinfo.c:380
#1  0x00007ffff65ff826 in zoneinfo_new (
    type=0x7ffff6801480 <PyZoneInfo_ZoneInfoType>, args=<optimized out>, 
    kw=<optimized out>) at /root/cpython/Modules/_zoneinfo.c:274
#2  0x000055555562a635 in type_call (
    type=type at entry=0x7ffff6801480 <PyZoneInfo_ZoneInfoType>, 
    args=args at entry=0x7ffff6fb7520, kwds=kwds at entry=0x0)
    at Objects/typeobject.c:1020
#3  0x00005555555c3018 in _PyObject_MakeTpCall (
    tstate=tstate at entry=0x555555b2c350, 
    callable=callable at entry=0x7ffff6801480 <PyZoneInfo_ZoneInfoType>, 
    args=args at entry=0x7ffff6f20df8, nargs=<optimized out>, keywords=0x0)
    at Objects/call.c:191
#4  0x00005555555ab48b in _PyObject_VectorcallTstate (kwnames=<optimized out>, 
    nargsf=<optimized out>, args=<optimized out>, callable=<optimized out>, 
    tstate=<optimized out>) at ./Include/cpython/abstract.h:112
#5  PyObject_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, 
    args=<optimized out>, callable=<optimized out>)
    at ./Include/cpython/abstract.h:123
#6  call_function (tstate=tstate at entry=0x555555b2c350, 
    pp_stack=pp_stack at entry=0x7fffffffdf30, oparg=<optimized out>, 
    kwnames=kwnames at entry=0x0) at Python/ceval.c:5121
#7  0x00005555555b17dd in _PyEval_EvalFrameDefault (tstate=<optimized out>, 
    f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3516
#8  0x00005555556864f5 in _PyEval_EvalFrame (throwflag=0, f=0x7ffff6f20c40, 
    tstate=0x555555b2c350) at ./Include/internal/pycore_ceval.h:40
#9  _PyEval_EvalCode (qualname=0x7ffff6e860f0, name=0x7ffff6e860f0, closure=0x0, 
    kwdefs=0x0, defcount=0, defs=0x0, kwstep=2, kwcount=0, kwargs=0x0, 
    kwnames=0x0, argcount=0, args=0x0, locals=0x0, globals=0x555555b2c350, 
    _co=0x7ffff6ee6d40, tstate=0x555555b2c350) at Python/ceval.c:4376
#10 _PyEval_EvalCodeWithName (qualname=0x0, name=0x0, closure=0x0, kwdefs=0x0, 
    defcount=0, defs=0x0, kwstep=2, kwcount=0, kwargs=0x0, kwnames=0x0, 
    argcount=0, args=0x0, locals=locals at entry=0x0, 
    globals=globals at entry=0x555555b2c350, _co=0x7ffff6ee6d40, 
    _co at entry=0x7ffff6f20da0) at Python/ceval.c:4408
#11 PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, 
    kws=0x0, argcount=0, args=0x0, locals=locals at entry=0x0, 
    globals=globals at entry=0x555555b2c350, _co=0x7ffff6ee6d40, 
    _co at entry=0x7ffff6f20da0) at Python/ceval.c:4424
---Type <return> to continue, or q <return> to quit---
#12 PyEval_EvalCode (co=co at entry=0x7ffff6ee6d40, 
    globals=globals at entry=0x7ffff6f4e440, locals=locals at entry=0x7ffff6f4e440)
    at Python/ceval.c:857
#13 0x00005555556d69c6 in run_eval_code_obj (locals=0x7ffff6f4e440, 
    globals=0x7ffff6f4e440, co=0x7ffff6ee6d40, tstate=0x555555b2c350)
    at Python/pythonrun.c:1124
#14 run_mod (arena=0x7ffff6fa1910, flags=0x7fffffffe128, locals=0x7ffff6f4e440, 
    globals=0x7ffff6f4e440, filename=0x7ffff6e815d0, mod=<optimized out>)
    at Python/pythonrun.c:1145
#15 PyRun_FileExFlags (fp=fp at entry=0x555555b89b40, 
    filename_str=filename_str at entry=0x7ffff6f5a050 "/root/cpython/../backups/bpo41321.py", start=start at entry=257, globals=globals at entry=0x7ffff6f4e440, 
    locals=locals at entry=0x7ffff6f4e440, closeit=closeit at entry=1, 
    flags=0x7fffffffe128) at Python/pythonrun.c:1062
#16 0x00005555556d6b9d in PyRun_SimpleFileExFlags (fp=fp at entry=0x555555b89b40, 
    filename=<optimized out>, closeit=closeit at entry=1, 
    flags=flags at entry=0x7fffffffe128) at Python/pythonrun.c:397
#17 0x00005555556d70e3 in PyRun_AnyFileExFlags (fp=fp at entry=0x555555b89b40, 
    filename=<optimized out>, closeit=closeit at entry=1, 
    flags=flags at entry=0x7fffffffe128) at Python/pythonrun.c:80
#18 0x00005555555b52a0 in pymain_run_file (cf=0x7fffffffe128, 
    config=0x555555b28db0) at Modules/main.c:369
#19 pymain_run_python (exitcode=0x7fffffffe11c) at Modules/main.c:594
#20 Py_RunMain () at Modules/main.c:673
#21 0x00005555555b57d6 in pymain_main (args=0x7fffffffe210) at Modules/main.c:703
#22 Py_BytesMain (argc=<optimized out>, argv=<optimized out>)
    at Modules/main.c:727
#23 0x00007ffff7041b97 in __libc_start_main (main=0x5555555aa2b0 <main>, argc=2, 
    argv=0x7fffffffe368, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe358)
    at ../csu/libc-start.c:310
#24 0x00005555555b446a in _start ()

----------
messages: 373912
nosy: belopolsky, p-ganssle, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: Random segfaults during zoneinfo object creation stopped using Ctrl-C
type: crash
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Sat Jul 18 15:22:58 2020
From: report at bugs.python.org (David Friedman)
Date: Sat, 18 Jul 2020 19:22:58 +0000
Subject: [issue20840] AttributeError: 'module' object has no attribute
 'ArgumentParser'
In-Reply-To: <1393837548.4.0.445191461545.issue20840@psf.upfronthosting.co.za>
Message-ID: <1595100178.02.0.772507560488.issue20840@roundup.psfhosted.org>


David Friedman <davidgfriedman at gmail.com> added the comment:

I know this is 6 years too late, but I had this problem a few minutes ago on Python2.7.  Googling didn't find me anything relevant except this bug entry.  However, I found the cause myself: I had a test file named argparse.py (and an argparse.pyc) in the current directory (i.e. $PYTHONPATH) which was overriding the one in the main python library path. Once I renamed my argparse.py and argparse.pyc to something else, python found the real argparse and that message (the same one you saw) disappeared.

----------
nosy: +David Friedman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20840>
_______________________________________

From report at bugs.python.org  Sat Jul 18 15:27:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jul 2020 19:27:00 +0000
Subject: [issue41272] New clause in FOR and WHILE instead of ELSE
In-Reply-To: <1594413840.56.0.248219439277.issue41272@roundup.psfhosted.org>
Message-ID: <1595100420.93.0.919322968133.issue41272@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think this should be closed as 'rejected'.

1. I am strongly opposed to giving keywords strongly context-dependent alternate meanings.  I also don't think that the proposal could be parsed.  Currently, 'if' introduces a new, independent statement, and making it dependent is not backwards compatible.

2. The proposal is unnecessary as the conditions can already be detected, and being explicit is much more flexible than the proposal.

for i001 in iterable: pass  # i001 is a new local name.

try:
    i001
    <loop executed at least once>
except NameError:
    <loop never executed>

for i in range(5):
    if i > 3:
        break001 = True  # New local.
        break

try:
    break001
    < loop broke>
except NameError:
    < loop exited normally>

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41272>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:16:18 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:16:18 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595103378.12.0.751177326148.issue39603@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8ca8a2e8fb068863c1138f07e3098478ef8be12e by AMIR in branch 'master':
bpo-39603: Prevent header injection in http methods (GH-18485)
https://github.com/python/cpython/commit/8ca8a2e8fb068863c1138f07e3098478ef8be12e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:16:37 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:16:37 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595103397.94.0.20383487735.issue39603@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20678
pull_request: https://github.com/python/cpython/pull/21536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:16:45 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:16:45 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595103405.12.0.281625520084.issue39603@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20679
pull_request: https://github.com/python/cpython/pull/21537

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:16:51 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:16:51 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595103411.97.0.410084638312.issue39603@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20680
pull_request: https://github.com/python/cpython/pull/21538

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:17:00 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:17:00 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595103420.49.0.222290477378.issue39603@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20681
pull_request: https://github.com/python/cpython/pull/21539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:23:27 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 18 Jul 2020 20:23:27 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595103807.48.0.358461853038.issue39603@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The 3.9 and 3.8 backports are waiting for tests to complete. The 3.7 and 3.6 backports need to be merged by the RM (Ned). Then someone can close this issue.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:39:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:39:19 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595104759.74.0.648652633115.issue39603@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 668d321476d974c4f51476b33aaca870272523bf by Miss Islington (bot) in branch '3.8':
bpo-39603: Prevent header injection in http methods (GH-18485)
https://github.com/python/cpython/commit/668d321476d974c4f51476b33aaca870272523bf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:41:59 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 20:41:59 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595104919.18.0.0426717773549.issue39603@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 27b811057ff5e93b68798e278c88358123efdc71 by Miss Islington (bot) in branch '3.9':
bpo-39603: Prevent header injection in http methods (GH-18485)
https://github.com/python/cpython/commit/27b811057ff5e93b68798e278c88358123efdc71


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:01:03 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 18 Jul 2020 21:01:03 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1595106063.11.0.641637489719.issue29778@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> If you can put files in the root of the hard drive where Windows was
> installed, surely you have other, easier attack vectors.

A rooted path is resolved relative to the process working directory, and Python can be started with any current working directory. 

The default access control set on the root directory of a filesystem allows any authenticated user to create files or directories, such as "D:\python3.dll". That's if a filesystem even supports security. Removable drives are often formatted as FAT32 or exFAT, and FAT filesystems have no security.

The system drive (almost always "C:") has to be an NTFS filesystem, and its root directory is locked down a bit more. It's at high integrity level with a no-write-up rule for files, but not for directories. Only a logon at elevated integrity level (high or system level) can create "C:\python3.dll". OTOH, any authenticated user is still allowed to create a directory, such as "C:\DLLs", and is granted the right to create files in it such as "C:\DLLs\python3.dll".

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:19:57 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 21:19:57 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595107197.21.0.401380689596.issue41295@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c53b310e5926266ce267c44a168165cacd786d6e by scoder in branch 'master':
bpo-41295: Reimplement the Carlo Verre "hackcheck" (GH-21528)
https://github.com/python/cpython/commit/c53b310e5926266ce267c44a168165cacd786d6e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:20:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 21:20:08 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595107208.46.0.211679027122.issue41295@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20682
pull_request: https://github.com/python/cpython/pull/21540

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:20:18 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 21:20:18 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595107218.2.0.312970856862.issue41295@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20683
pull_request: https://github.com/python/cpython/pull/21541

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:39:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 21:39:06 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595108346.13.0.032145168462.issue41295@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 01ab9634601fc1a4f9ac5d72ddc022239d2543fe by Miss Islington (bot) in branch '3.9':
bpo-41295: Reimplement the Carlo Verre "hackcheck" (GH-21528)
https://github.com/python/cpython/commit/01ab9634601fc1a4f9ac5d72ddc022239d2543fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:37:49 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Jul 2020 21:37:49 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595108269.68.0.442650983814.issue41295@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 38d930f2ccbff6f93c4c54a7a6a1759266136504 by Miss Islington (bot) in branch '3.8':
bpo-41295: Reimplement the Carlo Verre "hackcheck" (GH-21528)
https://github.com/python/cpython/commit/38d930f2ccbff6f93c4c54a7a6a1759266136504


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 18:06:36 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 18 Jul 2020 22:06:36 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595109996.51.0.0110165556128.issue41295@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We have a buildbot failure: test_asyncio altered the execution environment. What does that mean? Victor?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 18:33:16 2020
From: report at bugs.python.org (M W)
Date: Sat, 18 Jul 2020 22:33:16 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595111596.75.0.0885390291174.issue39603@roundup.psfhosted.org>


Change by M W <maryannwilliams533 at gmail.com>:


----------
assignee:  -> christian.heimes
components: +SSL
nosy: +M W2, christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sat Jul 18 19:35:01 2020
From: report at bugs.python.org (kam193)
Date: Sat, 18 Jul 2020 23:35:01 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595115301.78.0.652312709322.issue41295@roundup.psfhosted.org>


kam193 <kam193 at wp.pl> added the comment:

@Stefan: Today I run unit tests for Flask-SQLAlchemy (v2.4.3) as well as for aioxmpp (another library reported this problem https://github.com/horazont/aioxmpp/issues/342). In both cases patch is successful: tests fail on Python 3.8.4 but pass on patched Python.

As for me it looks done. Thanks for everyone involved!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:35:55 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 03:35:55 +0000
Subject: [issue29642] Why does unittest.TestLoader.discover still rely on
 existence of __init__.py files?
In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za>
Message-ID: <1595129755.18.0.167144577388.issue29642@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
superseder:  -> unittest discovery doesn't detect namespace packages when given no parameters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29642>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:38:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 03:38:03 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1595129883.95.0.486350546596.issue23882@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I had rejected this idea in #29642. This is a copy of my comments in the issue.

---

I'm afraid this change makes testloader searches unrelated directory contains massive files (like node_modules).

I don't think loading all tests from whole namespace package is not usual use case.

When using import, (namespace) package name is explicitly specified.
Only specified name is searched.

In test loader's case, there are no such limit.
Loader may search millions of completely unrelated directories.
It may include directories in NFS or samba over slow network.

----------
nosy: +inada.naoki
versions: +Python 3.10 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:42:43 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 03:42:43 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1595130163.84.0.802171443726.issue23882@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I think people misunderstanding and misusing PEP 420, withouth knowing what is namespace package for.

I had wrote an article to describe namespace package is not a regular package.
https://dev.to/methane/don-t-omit-init-py-3hga

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:49:02 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 03:49:02 +0000
Subject: [issue35617] unittest discover does not work with implicit namespaces
In-Reply-To: <1546162337.0.0.646769357962.issue35617@roundup.psfhosted.org>
Message-ID: <1595130542.98.0.11548309886.issue35617@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> unittest discovery doesn't detect namespace packages when given no parameters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35617>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:55:53 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 03:55:53 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1595130953.39.0.341245240486.issue23882@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Searching into directory without __init__.py recursively is not only inefficient, but also dangerous.

 project/
   - mylib/
      - __init__.py
      - foo.py
   - tests/
      - __init__.py
      - test_foo.py
   - tools/
      - bin/
          - dangerous_script.py

What happens if `python -m unittest` is run in the project root?
Who excepts tools/bin/dangarous.py is executed?

My conclution is:

* People shouldn't abuse PEP 420.  Omitting __init__.py is allowed only for namespace package.
* Namespace package should be searched based on PEP 420 rule. Don't search into regular directory unless it is specified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Sun Jul 19 00:05:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jul 2020 04:05:09 +0000
Subject: [issue36723] Unittest Discovery for namespace subpackages dot
 notation fails
In-Reply-To: <1556219043.29.0.793780129066.issue36723@roundup.psfhosted.org>
Message-ID: <1595131509.27.0.8161170984.issue36723@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36723>
_______________________________________

From report at bugs.python.org  Sun Jul 19 00:37:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 04:37:03 +0000
Subject: [issue36723] Unittest Discovery for namespace subpackages dot
 notation fails
In-Reply-To: <1556219043.29.0.793780129066.issue36723@roundup.psfhosted.org>
Message-ID: <1595133423.38.0.874450110413.issue36723@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> unittest discovery doesn't detect namespace packages when given no parameters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36723>
_______________________________________

From report at bugs.python.org  Sun Jul 19 00:47:19 2020
From: report at bugs.python.org (=?utf-8?q?Abdulkadir_=C3=96zbudak?=)
Date: Sun, 19 Jul 2020 04:47:19 +0000
Subject: =?utf-8?q?=5Bissue41324=5D_En_az_ondal=C4=B1k_kaps=C3=BCl_API_ekleme?=
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1595134039.48.0.50834516854.issue41324@roundup.psfhosted.org>


Change by Abdulkadir ?zbudak <abdulkadirozbudak42 at gmail.com>:


----------
title: Add a minimal decimal capsule API -> En az ondal?k kaps?l API ekleme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Sun Jul 19 00:51:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jul 2020 04:51:49 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1595134309.61.0.792102181916.issue41324@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
title: En az ondal?k kaps?l API ekleme -> Add a minimal decimal capsule API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Sun Jul 19 01:13:42 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 19 Jul 2020 05:13:42 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595135622.15.0.642042291132.issue41311@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

The lack of exactness (and possibility of platform-dependent results, including, e.g., when a single platform changes its math libraries) certainly works against it.

But I think Raymond is more bothered by that there's no apparently _compelling_ use case, in the sense of something frequent enough in real life to warrant including it in the standard library.

For example, there's really no problem right now if you have a giant iterable _and_ you know its length.  I had a case where I had to sample a few hundred doubles from giant binary files of floats.  The "obvious" solution worked great:

    for o in sorted(random.sample(range(0, file_size, 8), 1000)):
        seek to offset o and read up 8 bytes

Now random access to that kind of iterable is doable, but a similar approach works fine too if it's sequential-only access to a one-shot iterator of known length:  pick the indices in advance, and skip over the iterator until each index is hit in turn.

It doesn't score much points for being faster than materializing a set or dict into a sequence first, since that's a micro-optimization justified only by current CPython implementation accidents.

Where it's absolutely needed is when there's a possibly-giant iterable of unknown length. Unlike Raymond, I think that's possibly worth addressing (it's not hard to find people asking about it on the web). But it's not a problem I've had in real life, so, ya, it's hard to act enthusiastic ;-)

PS: you should also guard against W > 1.0. No high-quality math library will create such a thing given these inputs, but testing only for exact equality to 1.0 is no cheaper and so needlessly optimistic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Sun Jul 19 01:27:02 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 19 Jul 2020 05:27:02 +0000
Subject: [issue41272] New clause in FOR and WHILE instead of ELSE
In-Reply-To: <1594413840.56.0.248219439277.issue41272@roundup.psfhosted.org>
Message-ID: <1595136422.2.0.752472542091.issue41272@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I completely agree that we should reject this, but you commit a very frequent mistake in programming try-expressions. The problem is, if the first option contains a NameError, second option will be executed.

It should be:

    try: i001
    except NameError: <loop never executed>
    else: <loop executed at least once>

And similarly for break001. You see, dependent `else` is needed sometimes. But of course Guido already covered this. :-)

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41272>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:06:01 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 06:06:01 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595138761.05.0.600179326536.issue41311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I agree that this could be out of scope for the random module
> but I wanted to make sure the reasons were considered.

I think we've done that.  Let's go ahead and close this one down.

In general, better luck can be had by starting with a common real world problem not adequately solved by the library, then creating a clean API for it, and lastly searching for the best algorithm to implement it.  It is much tougher the other way around, starting with an algorithm you like, then hoping to find a use case to justify it, and hoping to find an API that isn't a footgun for everyday users.

FWIW, reservoir sampling was considered at the outset when sample() was first designed.  Subsequent to that we've also evaluated a high quality PR for switching the internals to reservoir sampling, but it proved to be inferior to the current implementation in most respects (code complexity, computational overhead, speed, and entropy consumed); the only gain was some memory savings.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:08:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 06:08:37 +0000
Subject: [issue41272] New clause in FOR and WHILE instead of ELSE
In-Reply-To: <1594413840.56.0.248219439277.issue41272@roundup.psfhosted.org>
Message-ID: <1595138917.93.0.780221783134.issue41272@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I see that this was already moved to the mailing list.  Am marking this as closed.  If the mail list discussion proves favorable, feel free to reopen.

----------
nosy: +rhettinger
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41272>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:10:43 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 06:10:43 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1595139043.22.0.916571460154.issue41297@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Can we close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:13:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 06:13:34 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
In-Reply-To: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>
Message-ID: <1595139214.88.0.810102982515.issue41323@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:19:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2020 06:19:06 +0000
Subject: [issue41333] Convert OrderedDict.pop() to Argument Clinic
In-Reply-To: <1595082793.92.0.490500501555.issue41333@roundup.psfhosted.org>
Message-ID: <1595139546.22.0.642114897068.issue41333@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6bf3237379b17632db52cb39d181e8bac70173f3 by Serhiy Storchaka in branch 'master':
bpo-41333: Convert OrderedDict.pop() to Argument Clinic (GH-21534)
https://github.com/python/cpython/commit/6bf3237379b17632db52cb39d181e8bac70173f3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41333>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:19:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2020 06:19:41 +0000
Subject: [issue41333] Convert OrderedDict.pop() to Argument Clinic
In-Reply-To: <1595082793.92.0.490500501555.issue41333@roundup.psfhosted.org>
Message-ID: <1595139581.83.0.53962315889.issue41333@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41333>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:41:14 2020
From: report at bugs.python.org (=?utf-8?q?Jonas_Sch=C3=A4fer?=)
Date: Sun, 19 Jul 2020 06:41:14 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595140874.02.0.0595619893857.issue41295@roundup.psfhosted.org>


Jonas Sch?fer <jonas at zombofant.net> added the comment:

@kam193 Thanks for running the aioxmpp tests. I built the patched python yesterday, but I didn?t manage to get a virtualenv with it up&running.

Good to hear that the fix works as expected!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:55:37 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 19 Jul 2020 06:55:37 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1595141737.37.0.782160271822.issue41273@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

There have been sporadic buildbot failures in "test_asyncio" since this change, message being "1 test altered the execution environment", e.g.

https://buildbot.python.org/all/#/builders/129/builds/1443

Could someone please check if they are related?

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Sun Jul 19 02:57:55 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 19 Jul 2020 06:57:55 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595141875.78.0.975620014222.issue41295@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> test_asyncio altered the execution environment

That happened several times before in previous builds. I think there's just a part of the asyncio tests that is unreliable. I left a comment in issue 41273 since it might be related, the sporadic failures started appearing in the build following the merge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:14:14 2020
From: report at bugs.python.org (Justin Hodder)
Date: Sun, 19 Jul 2020 07:14:14 +0000
Subject: [issue41337] strangnedd with the parser
Message-ID: <1595142854.93.0.625652406.issue41337@roundup.psfhosted.org>


New submission from Justin Hodder <draltaicaphone at gmail.com>:

Here a colab that demostrates the bug
https://colab.research.google.com/drive/1OWSEoV7Wx-EBA_2IprNZoASNvXIky3iC?usp=sharing
++++the following code gives"received an invalid combination of arguments - got (Tensor, Tensor), but expected one of:" 
import torch
torch.nn.Linear(
torch.as_strided(torch.ones((4,6*5*5*70*10)),(4,6*5*5,10),(4,2,-1))
,torch.ones(10,6*5*6))
#(4,2,3),(2,3,1))
++++The following code gives "TypeError: ones(): argument 'size' (position 1) must be tuple of ints, not str import torch"
import torch
#torch.nn.Linear(
torch.as_strided(torch.ones((4,6*5*5*70*10)),(4,6*5*5,10),(4,2,-1))
,torch.ones(10,6*5*6)#)
#(4,2,3),(2,3,1))
++++

----------
components: Interpreter Core
files: pythos_parser_bug.ipynb
messages: 373937
nosy: Justin Hodder
priority: normal
severity: normal
status: open
title: strangnedd with the parser
versions: Python 3.6
Added file: https://bugs.python.org/file49325/pythos_parser_bug.ipynb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41337>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:15:02 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sun, 19 Jul 2020 07:15:02 +0000
Subject: [issue40828] shared memory problems with multiprocessing.Pool
In-Reply-To: <1590861441.57.0.917224278177.issue40828@roundup.psfhosted.org>
Message-ID: <1595142902.01.0.699508292491.issue40828@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Hi, Can you please confirm the python version in which you replicated this issue. I tried replicating (segmentation fault) this issue in python 3.8.0b3 but didn't succeed. And shared_memory isn't present in 3.7. Also, shared_memory is known to throw some warnings, and there is already a PR and issue open for that https://bugs.python.org/issue38119.

----------
nosy: +vinay0410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40828>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:37:57 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 19 Jul 2020 07:37:57 +0000
Subject: [issue41297] Remove doctest import from heapq
In-Reply-To: <1594763364.19.0.785950162701.issue41297@roundup.psfhosted.org>
Message-ID: <1595144277.13.0.85386197261.issue41297@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41297>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:41:33 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jul 2020 07:41:33 +0000
Subject: [issue41338] test_decimal emits DeprecationWarning due to
 PyUnicode_FromUnicode(NULL, size)
Message-ID: <1595144492.98.0.788138334745.issue41338@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Probably related to issue36346

./python -Wall -m test test_decimal  
0:00:00 load avg: 3.07 Run tests sequentially
0:00:00 load avg: 3.07 [1/1] test_decimal
/root/cpython/Lib/test/test_decimal.py:592: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  s = _testcapi.unicode_legacy_string('9.999999')
/root/cpython/Lib/test/test_decimal.py:592: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  s = _testcapi.unicode_legacy_string('9.999999')
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2834: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  s = _testcapi.unicode_legacy_string('ROUND_\x00UP')
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2828: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  c.rounding = _testcapi.unicode_legacy_string(rnd)
/root/cpython/Lib/test/test_decimal.py:2834: DeprecationWarning: PyUnicode_FromUnicode(NULL, size) is deprecated; use PyUnicode_New() instead
  s = _testcapi.unicode_legacy_string('ROUND_\x00UP')

== Tests result: SUCCESS ==

1 test OK.

Total duration: 14.8 sec
Tests result: SUCCESS

----------
components: Tests
messages: 373939
nosy: inada.naoki, xtreak
priority: normal
severity: normal
status: open
title: test_decimal emits DeprecationWarning due to PyUnicode_FromUnicode(NULL, size)
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41338>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:51:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jul 2020 07:51:01 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1595145061.69.0.756972209019.issue32528@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 700cb6617545cdb8a9e16bb2e6efe90788a60d4d by Miss Islington (bot) in branch '3.8':
bpo-32528: Document the change in inheritance of asyncio.CancelledError (GH-21474)
https://github.com/python/cpython/commit/700cb6617545cdb8a9e16bb2e6efe90788a60d4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:03:27 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 08:03:27 +0000
Subject: [issue41338] test_decimal emits DeprecationWarning due to
 PyUnicode_FromUnicode(NULL, size)
In-Reply-To: <1595144492.98.0.788138334745.issue41338@roundup.psfhosted.org>
Message-ID: <1595145807.92.0.056382777476.issue41338@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +20684
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21542

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41338>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:06:48 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jul 2020 08:06:48 +0000
Subject: [issue36777] unittest discover throws TypeError on namespace packages
In-Reply-To: <1556815623.31.0.225997144606.issue36777@roundup.psfhosted.org>
Message-ID: <1595146008.82.0.0839846048481.issue36777@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I didn't know packages without __init__.py are namespace packages back then and used empty packages. I guess it's related to the other issues with unittest and namespace packages issue36723, issue23882 and issue35617

----------
nosy: +inada.naoki
title: unittest discover throws TypeError on empty packages -> unittest discover throws TypeError on namespace packages

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36777>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:14:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2020 08:14:02 +0000
Subject: [issue41338] test_decimal emits DeprecationWarning due to
 PyUnicode_FromUnicode(NULL, size)
In-Reply-To: <1595144492.98.0.788138334745.issue41338@roundup.psfhosted.org>
Message-ID: <1595146442.27.0.371070391487.issue41338@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
nosy_count: 2.0 -> 3.0
pull_requests: +20685
pull_request: https://github.com/python/cpython/pull/21543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41338>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:50:01 2020
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 19 Jul 2020 08:50:01 +0000
Subject: [issue41320] async process closing after event loop closed
In-Reply-To: <1594971503.41.0.525176892628.issue41320@roundup.psfhosted.org>
Message-ID: <1595148601.43.0.464261404123.issue41320@roundup.psfhosted.org>


Change by Joongi Kim <me at daybreaker.info>:


----------
nosy: +achimnol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41320>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:05:28 2020
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 19 Jul 2020 09:05:28 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595149528.23.0.455221824957.issue41229@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

>From the given example, if I add "await q.aclose()" after "await q.asend(123456)" it does not leak the memory.

This is a good example showing that we should always wrap async generators with explicit "aclosing" context manager (which does not exist yet in the stdlib).
I'm already doing so by writing a custom library:
https://github.com/achimnol/aiotools/blob/ef7bf0ce/src/aiotools/context.py#L152

We may need to update the documentation to recommend explicit aclosing of async generators.

----------
nosy: +achimnol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:14:15 2020
From: report at bugs.python.org (Oscar Benjamin)
Date: Sun, 19 Jul 2020 09:14:15 +0000
Subject: [issue41311] Add a function to get a random sample from an iterable
 (reservoir sampling)
In-Reply-To: <1594858231.04.0.366290640753.issue41311@roundup.psfhosted.org>
Message-ID: <1595150055.36.0.560779704818.issue41311@roundup.psfhosted.org>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

Yeah, I guess it's a YAGNI.

Thanks Raymond and Tim for looking at this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41311>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:27:39 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Jul 2020 09:27:39 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595150859.12.0.437678497262.issue39603@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset ca75fec1ed358f7324272608ca952b2d8226d11a by Miss Islington (bot) in branch '3.7':
bpo-39603: Prevent header injection in http methods (GH-18485) (GH-21538)
https://github.com/python/cpython/commit/ca75fec1ed358f7324272608ca952b2d8226d11a


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:28:48 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Jul 2020 09:28:48 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595150928.34.0.418376477221.issue39603@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset f02de961b9f19a5db0ead56305fe0057a78787ae by Miss Islington (bot) in branch '3.6':
bpo-39603: Prevent header injection in http methods (GH-18485) (GH-21539)
https://github.com/python/cpython/commit/f02de961b9f19a5db0ead56305fe0057a78787ae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:32:11 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Jul 2020 09:32:11 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595151131.07.0.233284165381.issue39603@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Merged for release in 3.9.0b5, 3.8.5, 3.7.9, and 3.6.12. Thanks, everyone!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:33:58 2020
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 19 Jul 2020 09:33:58 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595151238.06.0.217282493018.issue41229@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

I've searched the Python documentation and the docs must be updated to explicitly state the necessity of aclose().

refs)
https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
https://www.python.org/dev/peps/pep-0525/

I'm not sure that what the original authors' intention is, but for me, it looks like that calling aclose() is an optional thing and the responsibility to call aclose() on async generators is left to the asyncgen-shutdown handler of the event loop.

The example in this issue show that we need to aclose asyncgens whenever we are done with it, even far before shutting down the event loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:39:49 2020
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 19 Jul 2020 09:39:49 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595151589.38.0.266779616835.issue41229@roundup.psfhosted.org>


Change by Joongi Kim <me at daybreaker.info>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:42:15 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Jul 2020 09:42:15 +0000
Subject: [issue39073] [security] email module incorrect handling of CR and LF
 newline characters in Address objects.
In-Reply-To: <1576586803.42.0.942657577592.issue39073@roundup.psfhosted.org>
Message-ID: <1595151735.69.0.381320881953.issue39073@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Merged for release in 3.9.0a6, 3.8.4, 3.7.8, 3.6.11, and 3.5.10.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39073>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:02:32 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 19 Jul 2020 10:02:32 +0000
Subject: [issue41337] strangnedd with the parser
In-Reply-To: <1595142854.93.0.625652406.issue41337@roundup.psfhosted.org>
Message-ID: <1595152952.5.0.217583019142.issue41337@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This doesn't appear to be a Python bug, but rather an issue with how you're using PyTorch. I suggest you ask for help on a PyTorch support forum, or maybe try StackOverflow.

----------
nosy: +eric.smith
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41337>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:03:55 2020
From: report at bugs.python.org (Alan Iwi)
Date: Sun, 19 Jul 2020 10:03:55 +0000
Subject: [issue41339] make queue.Queue objects iterable
Message-ID: <1595153035.37.0.668957068395.issue41339@roundup.psfhosted.org>


New submission from Alan Iwi <alan.iwi at stfc.ac.uk>:

It is possible to make `queue.Queue` and `queue.SimpleQueue` objects iterable by adding simple `__iter__` and `__next__` methods.  This is to suggest adding these methods to the existing `Queue` and `SimpleQueue` so that they are iterable by default.

```
class Fifo(SimpleQueue):

    def __iter__(self):
        return self

    def __next__(self):
        if not self.empty():
            return self.get()
        raise StopIteration
```

----------
components: Library (Lib)
messages: 373950
nosy: alaniwi
priority: normal
severity: normal
status: open
title: make queue.Queue objects iterable
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41339>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:04:50 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 19 Jul 2020 10:04:50 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595153090.36.0.701753753976.issue41229@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Huh, this is very weird. I can confirm that the async generator objects aren't cleaned up until loop shutdown on asyncio.

On the trio main branch, we don't yet use the `set_asyncgen_hooks` mechanism, and the async generator objects are cleaned up immediately.

However, if I check out this PR that will add it: https://github.com/python-trio/trio/pull/1564

...then we see the same bug happening with Trio: all the async generators are kept around until loop shutdown.

Also, it doesn't seem to be a circular references issue ? if I explicitly call `gc.collect()`, then the asyncgen destructors are still *not* called; only shutting down the loop does it.

This doesn't make any sense, because asyncio/trio only keep weak references to the async generator objects, so they should still be freed.

So maybe the `set_asyncgen_hooks` code introduces a reference leak on async generator objects, or something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:06:19 2020
From: report at bugs.python.org (Roger Gammans)
Date: Sun, 19 Jul 2020 10:06:19 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1595153179.38.0.714987623251.issue23882@roundup.psfhosted.org>


Roger Gammans <rgammans at gammascience.co.uk> added the comment:

But namespace packages are still useful for what PEP420 envisages and they should be able to have runnable tests.

For instance

 projectX/
   - interfaces/
         - proxyX.py
         - testX.py
 projectY/
   - intefaces/
         - proxyY.py
         - testY.py

Here interfaces is a namespace package and projectX and projectY are kept separate, perhaps to reduce dependency and/or for separation of concerns.

I don't think this is insurmountable - even taking into account Inada's very good point about dangerous_scripts. A full tests/ packages in on both projectX and projectY would allow their test to run. However, in some environments, it is normal to put the test alongside the code as shown here.

But some better documentation on this issue would advisable, and some guidance on the best practice.

Python has a complex ecosystem, and so an individual developer might hit this problem but be using a third party `framework`, which hasn't taken all of this on board. Eg. https://code.djangoproject.com/ticket/30403 . (I'm not really singling django out, although it's the one I hit) So it important that there is a clear understanding of the best way to deal with this case.

----------
nosy: +rgammans at gammascience.co.uk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:09:14 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 19 Jul 2020 10:09:14 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595153354.3.0.700276719258.issue41229@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

...On closer examination, it looks like that Trio PR has at least one test that checks that async generators are collected promptly after they stop being referenced, and that test passes:

https://github.com/python-trio/trio/pull/1564/files#diff-c79a78487c2f350ba99059813ea0c9f9R38

So, I have no idea what's going on here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:17:19 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 19 Jul 2020 10:17:19 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595153839.14.0.671858429538.issue41229@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Oh! I see it. This is actually working as intended.

What's happening is that the event loop will clean up async generators when they're garbage collected... but, this requires that the event loop get a chance to run. In the demonstration program, the main task creates lots of async generator objects, but never returns to the main loop. So they're all queued up to be collected, but it can't actually happen until you perform a real async operation. For example, try adding 'await asyncio.sleep(1)` before the input() call so that the event loop has a chance to run, and you'll see that the objects are collected immediately.

So this is a bit tricky, but this is actually expected behavior, and falls under the general category of "don't block the event loop, it will break stuff".

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:36:04 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Sun, 19 Jul 2020 10:36:04 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
Message-ID: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>


New submission from fj92f3jj923f923 <watashiwaher at gmail.com>:

Hi, all!

strdup implementation inside cpython/Python/strdup.c is not the best one.
It calls strlen + strcpy, which is the same as calling strlen twice + memcpy.
So I replaced it by the call of strlen + memcpy.

It is easy to look any implementation in any library.
Here for example:
https://code.woboq.org/userspace/glibc/string/strdup.c.html

So I fixed it here:
https://github.com/python/cpython/pull/21544

----------
components: C API
messages: 373955
nosy: fj92f3jj923f923
priority: normal
severity: normal
status: open
title: Not very good strcpy implementation in cpython/Python/strdup.c
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:36:53 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Sun, 19 Jul 2020 10:36:53 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595155013.35.0.696767337126.issue41340@roundup.psfhosted.org>


Change by fj92f3jj923f923 <watashiwaher at gmail.com>:


----------
keywords: +patch
pull_requests: +20686
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21544

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:47:02 2020
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 19 Jul 2020 10:47:02 +0000
Subject: [issue41229] Asynchronous generator memory leak
In-Reply-To: <1594123688.2.0.0110904549514.issue41229@roundup.psfhosted.org>
Message-ID: <1595155622.44.0.400991684941.issue41229@roundup.psfhosted.org>


Change by Joongi Kim <daybreaker12 at gmail.com>:


----------
nosy: +Joongi Kim
nosy_count: 6.0 -> 7.0
pull_requests: +20687
pull_request: https://github.com/python/cpython/pull/21545

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41229>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:02:44 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 19 Jul 2020 11:02:44 +0000
Subject: [issue41336] Random segfaults during zoneinfo object creation stopped
 using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595156564.73.0.902409577558.issue41336@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +20688
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:03:48 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 19 Jul 2020 11:03:48 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1595156628.36.0.643341805866.issue41205@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 10e466448f67850ed7bb2e2a4e7f017f2b050cad by Srinivas Reddy Thatiparthy (??????????  ?????? ?????????) in branch 'master':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
https://github.com/python/cpython/commit/10e466448f67850ed7bb2e2a4e7f017f2b050cad


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:03:58 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jul 2020 11:03:58 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1595156638.95.0.148840185729.issue41205@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +20689
pull_request: https://github.com/python/cpython/pull/21547

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:04:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jul 2020 11:04:06 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1595156646.91.0.355839033571.issue41205@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20690
pull_request: https://github.com/python/cpython/pull/21548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:08:34 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sun, 19 Jul 2020 11:08:34 +0000
Subject: [issue38169] Increase Code Coverage for SharedMemory and
 ShareableListe
In-Reply-To: <1568447071.93.0.822548908149.issue38169@roundup.psfhosted.org>
Message-ID: <1595156914.67.0.742599247178.issue38169@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Remove Check to prevent creating shared_memory with size 0. Will create a different issue for the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38169>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:10:07 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jul 2020 11:10:07 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1595157007.46.0.78659023579.issue41205@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8831162464138eb0267f4967b85710247ee95fde by Miss Islington (bot) in branch '3.9':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
https://github.com/python/cpython/commit/8831162464138eb0267f4967b85710247ee95fde


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:10:50 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jul 2020 11:10:50 +0000
Subject: [issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0
 to the 0 which is 1)
In-Reply-To: <1593816685.46.0.773129097137.issue41205@roundup.psfhosted.org>
Message-ID: <1595157050.83.0.154130297462.issue41205@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dac8a3a15647d016842e2ae7284cefa27ce5e838 by Miss Islington (bot) in branch '3.8':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
https://github.com/python/cpython/commit/dac8a3a15647d016842e2ae7284cefa27ce5e838


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41205>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:28:27 2020
From: report at bugs.python.org (Joseph Perez)
Date: Sun, 19 Jul 2020 11:28:27 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
Message-ID: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>


New submission from Joseph Perez <joperez at hotmail.fr>:

(This issue is already broached in https://bugs.python.org/issue38605, and a in some way in https://bugs.python.org/issue35834, but only as a secondary subject, that's why I've opened a ticket on this particular issue)

ForwardRef of ForwardRef are not currently evaluated by get_type_hints, only the first level is, as illustrated in these examples:
```python
from typing import ForwardRef, Optional, get_type_hints
def func(a: "Optional[\"int\"]"):
    pass
assert get_type_hints(func)["a"] == Optional[ForwardRef("int")] 
# one would expect get_type_hints(func)["a"] == Optional[int] 
```
```python
from __future__ import annotations
from typing import ForwardRef, Optional, get_type_hints
def func(a: Optional["int"]):
    pass
assert get_type_hints(func)["a"] == Optional[ForwardRef("int")]
# one would expect get_type_hints(func)["a"] == Optional[int] (which is the case without the import of __future__.annotations!)
```
On the one hand I find this behavior quite counter-intuitive; I rather think ForwardRef as kind of internal (and wonder why there is no leading underscore, like _GenericAlias where it's used) and I don't understand the purpose of exposing it as the result of the public API get_type_hints. By the way, if ForwardRef can be obtained by retrieving annotations without get_type_hints, stringified annotations (especially since PEP 563) make get_type_hints kind of mandatory, and thus make ForwardRef disappeared (only at the first level so ?)

On the other hand, the second example show that adoptions of postponed annotations can change the result of get_type_hints; several libraries relying of get_type_hints could be broken.

An other issue raised here is that if these ForwardRef are not evaluated by get_type_hints, how will be done their evaluatation by the user? It would require to retrieve some globalns/localns ? too bad, it's exactly what is doing get_type_hints. And if the ForwardRef is in a class field, the class globalns/localns will have to be kept somewhere while waiting to encounter these random ForwardRef; that's feasible, but really tedious.

Agreeing with Guido Von Rossum (https://bugs.python.org/msg370232), this behavior could be easily "fixed" in get_type_hints.
Actually, there would be only one line to change in ForwardRef._evaluate:
```python
# from
self.__forward_value__ = _type_check(
    eval(self.__forward_code__, globalns, localns),
    "Forward references must evaluate to types.",
    is_argument=self.__forward_is_argument__)
# to
self.__forward_value__ = _eval_type(
    _type_check(
        eval(
            self.__forward_code__, globalns, localns),
            "Forward references must evaluate to types.",
            is_argument=self.__forward_is_argument__,
        ),
    globalns,
    localns,
)

And if this fix could solve the "double ForwardRef" issue mentionned in https://bugs.python.org/issue38605, it would also resolve https://bugs.python.org/issue35834 in the same time, raising NameError in case of unknown ForwardRef with postponed annotation.

----------
messages: 373960
nosy: BTaskaya, eric.smith, gvanrossum, joperez, levkivskyi, lukasz.langa, vstinner
priority: normal
severity: normal
status: open
title: Recursive evaluation of ForwardRef (and PEP 563)
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:29:16 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 19 Jul 2020 11:29:16 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1595153179.38.0.714987623251.issue23882@roundup.psfhosted.org>
Message-ID: <CAEfz+TzZTkCUud7bY4OdvM6qY685712VgBVqcvbME4OQZHnqLA@mail.gmail.com>


Inada Naoki <songofacandy at gmail.com> added the comment:

In such case, both directories must be specified explicitly.

Test discovery doesn't know that a directory is namespace package or
namespace package. So it shouldn't assume it is namespace package unless
specified.

Note that PEP 420 searches namespace package only when it is specified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:44:46 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 19 Jul 2020 11:44:46 +0000
Subject: [issue41262] Convert memoryview to Argument Clinic
In-Reply-To: <1594324134.91.0.173002376427.issue41262@roundup.psfhosted.org>
Message-ID: <1595159086.59.0.916696930515.issue41262@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Thanks, I can confirm that the speedup for memoryview.cast() is large in microbenchmarks.

Still, if the speedup cannot be seen in programs like test_buffer,
the amount of code that's being added for a speedup < 5% in real
world programs is quite substantial (if you count the generated
code and the fast_call machinery).

But we can leave it in.  Preemptively, if someone sees this and
thinks the flood gates are open for _decimal:  No, it won't be
converted to AC.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41262>
_______________________________________

From report at bugs.python.org  Sun Jul 19 08:05:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jul 2020 12:05:01 +0000
Subject: [issue41339] make queue.Queue objects iterable
In-Reply-To: <1595153035.37.0.668957068395.issue41339@roundup.psfhosted.org>
Message-ID: <1595160301.3.0.560086766393.issue41339@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41339>
_______________________________________

From report at bugs.python.org  Sun Jul 19 08:38:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2020 12:38:29 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
Message-ID: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

int.__round__ was not converted to Argument Clinic because it is not impossible to express a correct signature for it in Python. But now we can at least make Argument Clinic not producing incorrect signature. And converting to Argument Clinic has a performance benefit.

$ ./python -m pyperf timeit -q --compare-to=../cpython-baseline/python "round(12345)"
Mean +- std dev: [/home/serhiy/py/cpython-baseline/python] 123 ns +- 6 ns -> [/home/serhiy/py/cpython-release/python] 94.4 ns +- 2.4 ns: 1.31x faster (-23%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-baseline/python "round(12345, 0)"
Mean +- std dev: [/home/serhiy/py/cpython-baseline/python] 159 ns +- 4 ns -> [/home/serhiy/py/cpython-release/python] 98.6 ns +- 2.4 ns: 1.61x faster (-38%)

$ ./python -m pyperf timeit -q --compare-to=../cpython-baseline/python "round(12345, -2)"
Mean +- std dev: [/home/serhiy/py/cpython-baseline/python] 585 ns +- 9 ns -> [/home/serhiy/py/cpython-release/python] 534 ns +- 14 ns: 1.09x faster (-9%)

----------
components: Argument Clinic, Interpreter Core
messages: 373963
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert int.__round__ to Argument Clinic
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Sun Jul 19 08:43:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2020 12:43:07 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595162587.17.0.897332106272.issue41342@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20691
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21549

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Sun Jul 19 09:36:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Jul 2020 13:36:01 +0000
Subject: [issue38169] Increase Code Coverage for SharedMemory and
 ShareableListe
In-Reply-To: <1568447071.93.0.822548908149.issue38169@roundup.psfhosted.org>
Message-ID: <1595165761.31.0.399771012097.issue38169@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset bfd0fbdc1352534b3c91b46dbae4285f5220acf4 by Vinay Sharma in branch 'master':
bpo-38169: Increase code coverage for SharedMemory and ShareableList (GH-16139)
https://github.com/python/cpython/commit/bfd0fbdc1352534b3c91b46dbae4285f5220acf4


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38169>
_______________________________________

From report at bugs.python.org  Sun Jul 19 09:36:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Jul 2020 13:36:13 +0000
Subject: [issue38169] Increase Code Coverage for SharedMemory and
 ShareableListe
In-Reply-To: <1568447071.93.0.822548908149.issue38169@roundup.psfhosted.org>
Message-ID: <1595165773.74.0.581912759625.issue38169@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38169>
_______________________________________

From report at bugs.python.org  Sun Jul 19 10:13:58 2020
From: report at bugs.python.org (kam193)
Date: Sun, 19 Jul 2020 14:13:58 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595168038.48.0.0676546100587.issue41295@roundup.psfhosted.org>


kam193 <kam193 at wp.pl> added the comment:

@Jonas: I know, running those tests isn't so easy, I think a few libraries are incompatible with python 3.9/3.10 yet or I didn't find right prerequisites. But fortunately, everything is running on patched 3.8, so after back-porting I can run it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sun Jul 19 10:49:49 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Jul 2020 14:49:49 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
Message-ID: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Mean +- std dev: [master_format] 3.54 us +- 0.06 us -> [clinic_format] 3.29 us +- 0.07 us: 1.08x faster (-7%)

Mean +- std dev: [master_conjugate] 3.56 us +- 0.09 us -> [clinic_conjugate] 3.32 us +- 0.06 us: 1.07x faster (-7%)

Mean +- std dev: [master__getnewargs__] 425 ns +- 18 ns -> [clinic__getnewargs__] 412 ns +- 7 ns: 1.03x faster (-3%)

----------
components: Argument Clinic
messages: 373966
nosy: corona10, larry
priority: normal
severity: normal
status: open
title: Convert complex methods to Argument Clinic
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Sun Jul 19 10:50:25 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Jul 2020 14:50:25 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595170225.51.0.636557894475.issue41343@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
assignee:  -> corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Sun Jul 19 10:56:07 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Jul 2020 14:56:07 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595170567.43.0.724204705687.issue41343@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +20692
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21550

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Sun Jul 19 11:10:26 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 19 Jul 2020 15:10:26 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595171426.67.0.605716049617.issue41342@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Sun Jul 19 11:15:24 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 19 Jul 2020 15:15:24 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595171724.86.0.489843847557.issue41295@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@?ukasz: this should be good for the 3.8.5 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Sun Jul 19 11:51:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2020 15:51:36 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595173896.38.0.72188965999.issue41343@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I wrote similar patch for __format__ and got similar tiny speed up. It is expectable. But I am surprised that you get a difference for conjugate() and __getnewargs__. It may be a compiler artifact.

In any case the benefit of converting to Argument Clinic in this case is adding signatures for these methods.

----------
nosy: +mark.dickinson, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Sun Jul 19 12:50:58 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 19 Jul 2020 16:50:58 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595177458.5.0.91039376033.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20693
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sun Jul 19 13:38:12 2020
From: report at bugs.python.org (Greg Lindahl)
Date: Sun, 19 Jul 2020 17:38:12 +0000
Subject: [issue38227] Setting a signal handler gets multiprocessing.Pool stuck
In-Reply-To: <1568929295.79.0.555392640133.issue38227@roundup.psfhosted.org>
Message-ID: <1595180292.6.0.98708977344.issue38227@roundup.psfhosted.org>


Change by Greg Lindahl <lindahl at pbm.com>:


----------
nosy: +wumpus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38227>
_______________________________________

From report at bugs.python.org  Sun Jul 19 14:21:00 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 19 Jul 2020 18:21:00 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595182860.2.0.919493552768.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20694
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sun Jul 19 14:55:29 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 19 Jul 2020 18:55:29 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595184929.91.0.280705771179.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20695
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sun Jul 19 14:55:43 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 19 Jul 2020 18:55:43 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595184943.33.0.9796472704.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20696
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sun Jul 19 14:58:17 2020
From: report at bugs.python.org (David Bolen)
Date: Sun, 19 Jul 2020 18:58:17 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1595185097.53.0.220427440081.issue41273@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I can at least confirm that this commit is the source of the issue on the Windows 10 buildbot.  Interactively, it fails every time with it in place (unlike the buildbot which has had the occasional success) and passes reliably with it reverted.

The error arises during the SubprocessProactorTests test suite, but seemingly not with a specific test, just something that shows up when the entire suite is run.  At least I haven't been able to get it to occur by running individual tests.

Since the buildbot test output hides the underlying exception, here's the details of the two unraisable exceptions in question from test_asyncio.test_subprocess.SubprocessProactorTests.  I enabled tracemalloc but the original allocation is from the common utils module so probably not that much extra help:

D:\test\cpython\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed <PipeHandle handle=424>
  _warn(f"unclosed {self!r}", ResourceWarning, source=self)
Object allocated at (most recent call last):
  File "D:\test\cpython\lib\asyncio\windows_utils.py", lineno 164
    self.stdout = PipeHandle(stdout_rh)
D:\test\cpython\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed <PipeHandle handle=476>
  _warn(f"unclosed {self!r}", ResourceWarning, source=self)
Object allocated at (most recent call last):
  File "D:\test\cpython\lib\asyncio\windows_utils.py", lineno 166
    self.stderr = PipeHandle(stderr_rh)
Exception ignored in: <function _ProactorBasePipeTransport.__del__ at 0x000001DEB55D14B0>
Traceback (most recent call last):
  File "D:\test\cpython\lib\asyncio\proactor_events.py", line 115, in __del__
    _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
  File "D:\test\cpython\lib\asyncio\proactor_events.py", line 79, in __repr__
    info.append(f'fd={self._sock.fileno()}')
  File "D:\test\cpython\lib\asyncio\windows_utils.py", line 102, in fileno
    raise ValueError("I/O operation on closed pipe")
ValueError: I/O operation on closed pipe
Exception ignored in: <function _ProactorBasePipeTransport.__del__ at 0x000001DEB55D14B0>
Traceback (most recent call last):
  File "D:\test\cpython\lib\asyncio\proactor_events.py", line 115, in __del__
    _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
  File "D:\test\cpython\lib\asyncio\proactor_events.py", line 79, in __repr__
    info.append(f'fd={self._sock.fileno()}')
  File "D:\test\cpython\lib\asyncio\windows_utils.py", line 102, in fileno
    raise ValueError("I/O operation on closed pipe")
ValueError: I/O operation on closed pipe

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:10:12 2020
From: report at bugs.python.org (Tony)
Date: Sun, 19 Jul 2020 19:10:12 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1595185812.37.0.834911594001.issue41273@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

I see, I'll start working on a fix soon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:11:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 19:11:47 +0000
Subject: [issue41339] make queue.Queue objects iterable
In-Reply-To: <1595153035.37.0.668957068395.issue41339@roundup.psfhosted.org>
Message-ID: <1595185907.82.0.0823053648947.issue41339@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I prefer the current API because it makes the blocking step explicit.  That isn't the kind of thing that should be hidden behind a "for" or buried in another tool that accepts an iterable argument, sorted(q), for example. 

Also, the get() method supports two arguments "block" and "timeout" which would be inaccessible by a iterator.

The typical use case for queue objects is to process the gets one-at-a-time, blocking until a job arrives.  Queues typically start out empty.  And if they become empty later, it doesn't usually mean that there will be no more job requests.  This would make it awkward to use the proposed feature in real code without introducing an unnecessary extra level of nesting.

    -- Code with current API --
    while True:
        job = q.get()
        work(job)

    -- Code with proposed API --
    while True:          # Needed to restart when the queue is empty.
        for job in q:    # Consumes all currently available jobs.
            work(job)    # Now nested two layers deep.
        sleep(0.1)       # Prevent spin-wait bug.

For most users, the proposed feature would likely be a distraction that leads them away from the cleaner, lower overhead solution with an explicit get().  Also, the spin-wait bug is hard to see during code review or debugging.

FWIW, there is a race-condition in your definition of __next__().  The LBYL logic should probably be replaced with EAFP logic putting a get_nowait() inside a try/except.

I suggest taking this to the python-ideas mail list to discuss the pros and cons.  There are cases where a for-loop would look nicer than what we have now, so people might find the proposal acceptable despite all the problems listed above.

I'll mark this as closed.  If the idea gains traction on the mail list, feel free to re-open.

----------
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41339>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:12:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 19:12:50 +0000
Subject: [issue41336] Random segfaults during zoneinfo object creation stopped
 using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595185970.84.0.421373272116.issue41336@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:59:08 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 19 Jul 2020 19:59:08 +0000
Subject: [issue31821] pause_reading() doesn't work from connection_made()
In-Reply-To: <1508438943.14.0.213398074469.issue31821@psf.upfronthosting.co.za>
Message-ID: <1595188748.18.0.941066810487.issue31821@roundup.psfhosted.org>


Change by Alex Gr?nholm <alex.gronholm at nextday.fi>:


----------
nosy: +alex.gronholm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31821>
_______________________________________

From report at bugs.python.org  Sun Jul 19 16:24:01 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 19 Jul 2020 20:24:01 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595190241.03.0.494836715548.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20697
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Sun Jul 19 17:13:23 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 19 Jul 2020 21:13:23 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1595193203.04.0.984923135791.issue39017@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Given that a CVE was assigned for this, I think it'd be better if the news were in the 'Security' category and not 'Library'.

----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Sun Jul 19 17:32:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 21:32:07 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595194327.94.0.310003979225.issue41342@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't have an opinion on the PR but want to point-out the Argument Clinic itself doesn't provide a performance benefit.  Anything that it does can also be done directly by the code itself, including vectorcall logic.  You should be able to optimize function calls without using the Argument Clinic.

That said, it would be great is someone were to work on building-out AC to support more interesting argument patterns like those in round().  It would be great if there were complete, correct support right out of the box.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Sun Jul 19 18:04:42 2020
From: report at bugs.python.org (Tony)
Date: Sun, 19 Jul 2020 22:04:42 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1595196282.48.0.12556892458.issue41273@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

Ok so I checked and the PR I am currently having a CR on fixes this issue: https://github.com/python/cpython/pull/21446

Do you want me to make a different PR tomorrow that fixes this specific issue to get it faster to master or is it ok to wait a bit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Sun Jul 19 18:08:48 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Sun, 19 Jul 2020 22:08:48 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595196528.67.0.482274871079.issue41045@roundup.psfhosted.org>


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


----------
pull_requests: +20698
pull_request: https://github.com/python/cpython/pull/21552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Sun Jul 19 18:41:59 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Sun, 19 Jul 2020 22:41:59 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595198519.56.0.665699533887.issue41045@roundup.psfhosted.org>


Ama Aje My Fren <amaajemyfren at gmail.com> added the comment:

Hello all,

I have attempted to resolve this issue by adding some comments to PR21464 and later provided a reworded PR21509 that attempts to resolve this using ideas from @rishi93.

Finally I have tried to document f-string within pydoc itself with PR21552.

I request please that they be marked with skip-news. Also request feedback on the PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Sun Jul 19 19:54:49 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jul 2020 23:54:49 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595202889.86.0.298556366027.issue41340@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think we need to spend much effort on this implementation, since it will only be used if the system libc doesn't have a strdup already.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 19 19:57:08 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 23:57:08 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595203028.25.0.615854388746.issue41342@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg373973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Sun Jul 19 19:58:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2020 23:58:29 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595203109.69.0.597807960683.issue41342@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't have an opinion on the PR but want to point-out the Argument Clinic itself doesn't provide a performance benefit.  Anything that it does can also be done directly by the code itself, including vectorcall logic.  You should be able to optimize the function calls without using the Argument Clinic.

That said, it would be great if someone were to work on building-out AC to support more interesting argument patterns like those in round().  Ideally, AC would provide complete, correct support right out of the box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Sun Jul 19 21:37:50 2020
From: report at bugs.python.org (Joseph Perez)
Date: Mon, 20 Jul 2020 01:37:50 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595209070.98.0.341506546319.issue41341@roundup.psfhosted.org>


Change by Joseph Perez <joperez at hotmail.fr>:


----------
keywords: +patch
pull_requests: +20699
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21553

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 19 21:47:38 2020
From: report at bugs.python.org (Joseph Perez)
Date: Mon, 20 Jul 2020 01:47:38 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595209658.57.0.115177327967.issue41341@roundup.psfhosted.org>


Joseph Perez <joperez at hotmail.fr> added the comment:

Ok, I admit that I did not think about recursive type when proposing this "fix".
I've tried an implementation that just stop when recursion is encountered in a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 19 23:03:02 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jul 2020 03:03:02 +0000
Subject: [issue41338] test_decimal emits DeprecationWarning due to
 PyUnicode_FromUnicode(NULL, size)
In-Reply-To: <1595144492.98.0.788138334745.issue41338@roundup.psfhosted.org>
Message-ID: <1595214182.65.0.030022763205.issue41338@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 902356a7b0564e2c9659aaec56211de4d37109d0 by Inada Naoki in branch 'master':
bpo-41338: Fix DeprecationWarning in tests (GH-21542)
https://github.com/python/cpython/commit/902356a7b0564e2c9659aaec56211de4d37109d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41338>
_______________________________________

From report at bugs.python.org  Sun Jul 19 23:03:12 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jul 2020 03:03:12 +0000
Subject: [issue41338] test_decimal emits DeprecationWarning due to
 PyUnicode_FromUnicode(NULL, size)
In-Reply-To: <1595144492.98.0.788138334745.issue41338@roundup.psfhosted.org>
Message-ID: <1595214192.47.0.59896876016.issue41338@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41338>
_______________________________________

From report at bugs.python.org  Sun Jul 19 23:33:05 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jul 2020 03:33:05 +0000
Subject: [issue36777] unittest discover throws TypeError on namespace packages
In-Reply-To: <1556815623.31.0.225997144606.issue36777@roundup.psfhosted.org>
Message-ID: <1595215985.91.0.951783632944.issue36777@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

This issue is not duplicate of #23882.
In the example, test1 and test1.test2 are namespace package. But they are specified explicitly.

`./python.exe -m unittest discover test1.test2`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36777>
_______________________________________

From report at bugs.python.org  Sun Jul 19 23:45:02 2020
From: report at bugs.python.org (David Bolen)
Date: Mon, 20 Jul 2020 03:45:02 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1595216702.87.0.0972305175538.issue41273@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

First, I also no longer see the error with a local PR 21446 build on the Win10 buildbot.

As for timing, I believe policy is to revert, but in my view it can probably depend on how short "a bit" is for the fix.  We've been in this state for 4-5 days already, so one more day, for example, probably won't matter that much.

If it looks like it'll be longer, or the timing is uncertain, then I'd probably suggest reverting until the new PR is ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Mon Jul 20 00:14:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 04:14:20 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595218460.71.0.607705394471.issue41342@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, you can do this without Argument Clinic, but Argument Clinic allows to hide the use of unstable private API and cumbersome code under macros and in generated files.

> That said, it would be great if someone were to work on building-out AC to support more interesting argument patterns like those in round().

The problem is not only in Argument Clinic (and the Argument Clinic part is mainly solved). The problem is that currently it is not possible to express the signature of int.__round__() (and dict.get(), and getattr()) in Python syntax, and the inspect module does not support any non-Python syntax for this either. Once we invent the way to express it, supporting it in Argument Clinic will be merely technical problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Mon Jul 20 01:43:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Jul 2020 05:43:43 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595223823.34.0.469548616427.issue41343@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> But I am surprised that you get a difference for conjugate() and __getnewargs__. 

It could be a noise :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Mon Jul 20 01:47:37 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Jul 2020 05:47:37 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595224057.61.0.517954962495.issue41343@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Hmm, I re-ran all the benchmark.
- conjugate => It looks like noise. 
- __getnewargs__ -> consistently showing performance improvement. (2-3%)

FYI, I ran benchmarks on the macOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:19:26 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jul 2020 06:19:26 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595225966.25.0.0522229548485.issue40741@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7cf1cb36ecafabff363790d245f809d3894fbbaf by Erlend Egeberg Aasland in branch 'master':
bpo-40741: Update macOS installer to use SQLite 3.32.3 (GH-20979)
https://github.com/python/cpython/commit/7cf1cb36ecafabff363790d245f809d3894fbbaf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:19:55 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 06:19:55 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595225995.34.0.285008745798.issue40741@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20700
pull_request: https://github.com/python/cpython/pull/21554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:20:02 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 06:20:02 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595226002.92.0.942288341641.issue40741@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20701
pull_request: https://github.com/python/cpython/pull/21555

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:23:00 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Mon, 20 Jul 2020 06:23:00 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595226180.88.0.657482538809.issue41340@roundup.psfhosted.org>


fj92f3jj923f923 <watashiwaher at gmail.com> added the comment:

Got it.
But the fix is quite easy as I see, and does not require much affort too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:37:57 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 06:37:57 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595227077.02.0.7117721855.issue40741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2fbb0d8da95b3068dff436f7aacec1058c9b3f2a by Miss Islington (bot) in branch '3.9':
bpo-40741: Update macOS installer to use SQLite 3.32.3 (GH-20979)
https://github.com/python/cpython/commit/2fbb0d8da95b3068dff436f7aacec1058c9b3f2a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:37:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2020 06:37:54 +0000
Subject: [issue41336] Sporadic segfaults during zoneinfo object creation
 stopped using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595227074.84.0.196614668794.issue41336@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Random segfaults during zoneinfo object creation stopped using Ctrl-C -> Sporadic segfaults during zoneinfo object creation stopped using Ctrl-C

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:38:00 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 06:38:00 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595227080.36.0.746133395642.issue40741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 892fc8d328c65f7fd076b10c94380eccf7427422 by Miss Islington (bot) in branch '3.8':
bpo-40741: Update macOS installer to use SQLite 3.32.3 (GH-20979)
https://github.com/python/cpython/commit/892fc8d328c65f7fd076b10c94380eccf7427422


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:38:55 2020
From: report at bugs.python.org (Heyi Tang)
Date: Mon, 20 Jul 2020 06:38:55 +0000
Subject: [issue41318] Better error message of "Cannot recover from stack
 overflow."
In-Reply-To: <1594957263.52.0.457195944754.issue41318@roundup.psfhosted.org>
Message-ID: <1595227135.84.0.666784627531.issue41318@roundup.psfhosted.org>


Change by Heyi Tang <tangheyi.09 at gmail.com>:


----------
versions: +Python 3.8 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41318>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:38:43 2020
From: report at bugs.python.org (Heyi Tang)
Date: Mon, 20 Jul 2020 06:38:43 +0000
Subject: [issue41318] Better error message of "Cannot recover from stack
 overflow."
In-Reply-To: <1594957263.52.0.457195944754.issue41318@roundup.psfhosted.org>
Message-ID: <1595227123.87.0.0171086300788.issue41318@roundup.psfhosted.org>


Change by Heyi Tang <tangheyi.09 at gmail.com>:


----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41318>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:39:14 2020
From: report at bugs.python.org (Heyi Tang)
Date: Mon, 20 Jul 2020 06:39:14 +0000
Subject: [issue41318] Better error message of "Cannot recover from stack
 overflow."
In-Reply-To: <1594957263.52.0.457195944754.issue41318@roundup.psfhosted.org>
Message-ID: <1595227154.83.0.173147253465.issue41318@roundup.psfhosted.org>


Change by Heyi Tang <tangheyi.09 at gmail.com>:


----------
versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41318>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:58:57 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jul 2020 06:58:57 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595228337.22.0.321204818648.issue41340@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Can we just remove strdup.c? How about hypot.c?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Mon Jul 20 03:35:36 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Mon, 20 Jul 2020 07:35:36 +0000
Subject: [issue41344] SharedMemory crash when size is 0
Message-ID: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>


New submission from Vinay Sharma <vinay0410sharma at gmail.com>:

On running this: shm = SharedMemory(create=True, size=0)
I get the following error:



Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/multiprocessing/shared_memory.py", line 111, in __init__
    self._mmap = mmap.mmap(self._fd, size)
ValueError: cannot mmap an empty file
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 63, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5, in <module>
    from apport.report import Report
  File "/usr/lib/python3/dist-packages/apport/report.py", line 30, in <module>
    import apport.fileutils
  File "/usr/lib/python3/dist-packages/apport/fileutils.py", line 23, in <module>
    from apport.packaging_impl import impl as packaging
  File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 24, in <module>
    import apt
  File "/usr/lib/python3/dist-packages/apt/__init__.py", line 23, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'

Original exception was:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/multiprocessing/shared_memory.py", line 111, in __init__
    self._mmap = mmap.mmap(self._fd, size)
ValueError: cannot mmap an empty file
>>> shm = SharedMemory(create=True, size=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/multiprocessing/shared_memory.py", line 111, in __init__
    self._mmap = mmap.mmap(self._fd, size)
ValueError: cannot mmap an empty file
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 63, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5, in <module>
    from apport.report import Report
  File "/usr/lib/python3/dist-packages/apport/report.py", line 30, in <module>
    import apport.fileutils
  File "/usr/lib/python3/dist-packages/apport/fileutils.py", line 23, in <module>
    from apport.packaging_impl import impl as packaging
  File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 24, in <module>
    import apt
  File "/usr/lib/python3/dist-packages/apt/__init__.py", line 23, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'

Original exception was:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/multiprocessing/shared_memory.py", line 111, in __init__
    self._mmap = mmap.mmap(self._fd, size)
ValueError: cannot mmap an empty file


This can be simply resolved by adding a check when size passed is 0, so that a shared memory segment is never created.
Currently, the following is coded:

if not size >= 0:
    raise ValueError("'size' must be a positive integer")

I believe this should be changed to:
if not size > 0:
    raise ValueError("'size' must be a positive integer")

As zero is not a positive and integer and is causing problems.

----------
components: Library (Lib)
messages: 373990
nosy: vinay0410
priority: normal
severity: normal
status: open
title: SharedMemory crash when size is 0
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Mon Jul 20 03:58:52 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Mon, 20 Jul 2020 07:58:52 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595231932.39.0.139038608552.issue41344@roundup.psfhosted.org>


Change by Vinay Sharma <vinay0410sharma at gmail.com>:


----------
keywords: +patch
pull_requests: +20702
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21556

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:43:06 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 08:43:06 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595234586.42.0.803616423033.issue37703@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d42528a3a2c7d79fd2e6c9f2a02f3ce12d44c8cc by Vinay Sharma in branch 'master':
bpo-37703: improve asyncio.gather documentation regarding cancellation (GH-15312)
https://github.com/python/cpython/commit/d42528a3a2c7d79fd2e6c9f2a02f3ce12d44c8cc


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:43:11 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 08:43:11 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595234591.35.0.990714811517.issue37703@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20703
pull_request: https://github.com/python/cpython/pull/21557

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:43:26 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 08:43:26 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595234606.49.0.549551370505.issue37703@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20705
pull_request: https://github.com/python/cpython/pull/21559

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:43:19 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 08:43:19 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595234599.23.0.104172118642.issue37703@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20704
pull_request: https://github.com/python/cpython/pull/21558

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:46:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jul 2020 08:46:03 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1595234763.78.0.690786066468.issue23882@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:49:34 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jul 2020 08:49:34 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595234974.91.0.392076360715.issue37703@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 04:51:57 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 20 Jul 2020 08:51:57 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595235117.02.0.123253340621.issue41344@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +davin, pitrou
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Mon Jul 20 05:01:49 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 09:01:49 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595235709.09.0.536621175228.issue37703@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 46634b7aa82f014cd0039afb7f0ed860605beb9d by Miss Islington (bot) in branch '3.9':
bpo-37703: improve asyncio.gather documentation regarding cancellation (GH-15312)
https://github.com/python/cpython/commit/46634b7aa82f014cd0039afb7f0ed860605beb9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 05:01:02 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 09:01:02 +0000
Subject: [issue37703] Inconsistent gather with child exception
In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>
Message-ID: <1595235662.97.0.114529954588.issue37703@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 58f59a962180123a6d29ece512d198b365726b33 by Miss Islington (bot) in branch '3.8':
bpo-37703: improve asyncio.gather documentation regarding cancellation (GH-15312)
https://github.com/python/cpython/commit/58f59a962180123a6d29ece512d198b365726b33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 20 05:01:47 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 20 Jul 2020 09:01:47 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595235707.47.0.875210771224.issue39093@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Trying to manually link the PR to this issue, I have opened https://github.com/python/cpython/pull/21532

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Mon Jul 20 05:14:55 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jul 2020 09:14:55 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1595236495.33.0.189252393392.issue23882@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +20706
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Mon Jul 20 05:15:11 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Mon, 20 Jul 2020 09:15:11 +0000
Subject: [issue38018] Increase Code Coverage for multiprocessing.shared_memory
In-Reply-To: <1567519085.54.0.887939969587.issue38018@roundup.psfhosted.org>
Message-ID: <1595236511.67.0.3021021341.issue38018@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Closing this, as all the necessary PRs have been merged.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38018>
_______________________________________

From report at bugs.python.org  Mon Jul 20 05:16:20 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Mon, 20 Jul 2020 09:16:20 +0000
Subject: [issue39584] multiprocessing.shared_memory: MacOS crashes by running
 attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1595236580.19.0.568929196199.issue39584@roundup.psfhosted.org>


Change by Vinay Sharma <vinay0410sharma at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Mon Jul 20 06:19:05 2020
From: report at bugs.python.org (Tony)
Date: Mon, 20 Jul 2020 10:19:05 +0000
Subject: [issue41273] asyncio: proactor read transport: use recv_into instead
 of recv
In-Reply-To: <1594415336.97.0.770801888844.issue41273@roundup.psfhosted.org>
Message-ID: <1595240345.95.0.522004146872.issue41273@roundup.psfhosted.org>


Tony <tony.solomonik at gmail.com> added the comment:

If the error is not resolved yet, I would prefer if we revert this change then.

The new PR is kinda big I don't know when it will be merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41273>
_______________________________________

From report at bugs.python.org  Mon Jul 20 06:23:49 2020
From: report at bugs.python.org (Krzysiek)
Date: Mon, 20 Jul 2020 10:23:49 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1595240629.66.0.91687679094.issue9694@roundup.psfhosted.org>


Krzysiek <krzychdid at interia.pl> added the comment:

It seems the discussion has so far revolved around 'optional' arguments with `required=True`.

What about the other way around?

While trying to set `required=False` for a positional argument raises an exception, it is still possible to make the positional argument effectively optional by `nargs='?'` (it is then printed in brackets in usage message).

----------
nosy: +kkarbowiak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Mon Jul 20 07:01:51 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 20 Jul 2020 11:01:51 +0000
Subject: [issue30044] shutil.copystat should (allow to) copy ownership,
 and other attributes
In-Reply-To: <1491925353.8.0.782070431072.issue30044@psf.upfronthosting.co.za>
Message-ID: <1595242911.52.0.565267141103.issue30044@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Since the need to copy file ownership is common, I think there could be space for a new copy3() function which copies ownership + extended attributes (where possible). In detail:

- on Windows this can be achieved by using CopyFileEx, which would also provide better overall performances than the current readinto() implementation. This was the original approach used in BPO-33671, discarded after Eryk pointed out that ACLs should not be copied.

- on macOS we can use fcopyfile() (which is already exposed privately) + COPYFILE_ALL, see http://www.manpagez.com/man/3/fcopyfile/

- on all other UNIX we can use the current shutil.copystat() (which already copies xattrs) + os.chown(). I am not entirely sure this would achieve a "full ACLs copy" though, or what would be needed exactly to achieve that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30044>
_______________________________________

From report at bugs.python.org  Mon Jul 20 07:37:45 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 20 Jul 2020 11:37:45 +0000
Subject: [issue30044] shutil.copystat should (allow to) copy ownership,
 and other attributes
In-Reply-To: <1491925353.8.0.782070431072.issue30044@psf.upfronthosting.co.za>
Message-ID: <1595245065.56.0.0232229243693.issue30044@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Sorry, after re-reading Eryk's comment, it seems I'm not correct about CopyFileEx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30044>
_______________________________________

From report at bugs.python.org  Mon Jul 20 07:43:46 2020
From: report at bugs.python.org (Michal Arbet)
Date: Mon, 20 Jul 2020 11:43:46 +0000
Subject: [issue41345] Remote end closed connection without response
Message-ID: <1595245426.33.0.812684814237.issue41345@roundup.psfhosted.org>


New submission from Michal Arbet <michal.arbet at ultimum.io>:

Hi,

I'm not sure if this is really python bug, but I hope that you can check the issue.

Issue is that from time to time i'm getting exception from python when sending request to server which has http keepalive option turned on.

Requests send a request but in few miliseconds apache2 server is closing persistent connection by sending FIN packet which generate traceback.

I can reproduce it by following simple script.

#!/usr/bin/python3

import requests
from time import sleep

import logging
logging.basicConfig(level=logging.DEBUG)

s = requests.Session()
s.verify = False  # self-signed cert

counter = 0
txt = "test"
while True:
    counter = counter + 1
    s.post('http://localhost', data={counter:txt})
    sleep(5)

Everything is working fine, but from time to time I get following traceback. When FIN is received right after request was sent.

michalarbet at pixla:~/work$ ./request_test.py 
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:80
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 0
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 421, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 416, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.8/http/client.py", line 1332, in getresponse
    response.begin()
  File "/usr/lib/python3.8/http/client.py", line 303, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.8/http/client.py", line 272, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/michalarbet/.local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 719, in urlopen
    retries = retries.increment(
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 400, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "/usr/lib/python3/dist-packages/six.py", line 702, in reraise
    raise value.with_traceback(tb)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 421, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 416, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.8/http/client.py", line 1332, in getresponse
    response.begin()
  File "/usr/lib/python3.8/http/client.py", line 303, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.8/http/client.py", line 272, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./request_test.py", line 26, in <module>
    s.post('http://localhost', data={counter:txt})
  File "/home/michalarbet/.local/lib/python3.8/site-packages/requests/sessions.py", line 578, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/home/michalarbet/.local/lib/python3.8/site-packages/requests/sessions.py", line 530, in request
    resp = self.send(prep, **send_kwargs)
  File "/home/michalarbet/.local/lib/python3.8/site-packages/requests/sessions.py", line 643, in send
    r = adapter.send(request, **kwargs)
  File "/home/michalarbet/.local/lib/python3.8/site-packages/requests/adapters.py", line 498, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

Apache using keepalive.
/etc/apache2/apache2.conf:KeepAliveTimeout 5
/etc/apache2/apache2.conf:MaxKeepAliveRequests 100
/etc/apache2/apache2.conf:KeepAlive On


Sending also pcap file from different reproduce test, but behaviour is same.

----------
files: mycap.pcap
messages: 374000
nosy: Michal Arbet
priority: normal
severity: normal
status: open
title: Remote end closed connection without response
versions: Python 3.8
Added file: https://bugs.python.org/file49326/mycap.pcap

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:07:36 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 20 Jul 2020 12:07:36 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause crash
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1595246856.41.0.992449598573.issue39093@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +20707
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:51:39 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 12:51:39 +0000
Subject: [issue41336] Sporadic segfaults during zoneinfo object creation
 stopped using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595249499.91.0.232290038768.issue41336@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +20708
pull_request: https://github.com/python/cpython/pull/21563

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:51:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:51:32 +0000
Subject: [issue41336] Sporadic segfaults during zoneinfo object creation
 stopped using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595249492.94.0.132340893775.issue41336@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset eca2549f5a5048b44ca88b9555f1c62f094e3c12 by Zackery Spytz in branch 'master':
bpo-41336: Fix the error handling in zoneinfo_new_instance() (GH-21546)
https://github.com/python/cpython/commit/eca2549f5a5048b44ca88b9555f1c62f094e3c12


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:53:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:53:59 +0000
Subject: [issue41334] Convert str(), bytes() and bytearray() to Argument Clinic
In-Reply-To: <1595084331.14.0.93182273048.issue41334@roundup.psfhosted.org>
Message-ID: <1595249639.27.0.0551149596619.issue41334@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 12f433411bba8a0cdc4f09ba34472745ae9da0d1 by Serhiy Storchaka in branch 'master':
bpo-41334: Convert constructors of str, bytes and bytearray to Argument Clinic (GH-21535)
https://github.com/python/cpython/commit/12f433411bba8a0cdc4f09ba34472745ae9da0d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41334>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:53:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:53:32 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595249612.73.0.927913939464.issue41343@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e123012d79121ab543583631bb84c7fc27d06338 by Dong-hee Na in branch 'master':
bpo-41343: Convert methods of complex to Argument Clinic (GH-21550)
https://github.com/python/cpython/commit/e123012d79121ab543583631bb84c7fc27d06338


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:54:48 2020
From: report at bugs.python.org (Ilia Androshchuk)
Date: Mon, 20 Jul 2020 12:54:48 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595245426.33.0.812684814237.issue41345@roundup.psfhosted.org>
Message-ID: <1595249688.36.0.272127617145.issue41345@roundup.psfhosted.org>


Ilia Androshchuk <an7e at outlook.com> added the comment:

Hi Michal,
Which version of operating system and apache are you running?
I'll try to reproduce

----------
nosy: +an7e

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:56:10 2020
From: report at bugs.python.org (Felix Yan)
Date: Mon, 20 Jul 2020 12:56:10 +0000
Subject: [issue41346] test_thousand and compileall hangs on riscv64
Message-ID: <1595249770.4.0.20860830279.issue41346@roundup.psfhosted.org>


New submission from Felix Yan <felixonmars at archlinux.org>:

In my riscv64 build, test_thousand (test.test_multiprocessing_forkserver.WithProcessesTestBarrier) always hangs on some locking thing, and the compileall part during installation hangs the same way. I am not sure if it's toolchain related or something else, though.

Some relevant versions:

Linux riscv64-unknown-linux-gnu
Python 3.8.4
glibc 2.31
gcc 10.1.0

configure switches:

  ./configure --prefix=/usr \
              --enable-shared \
              --with-computed-gotos \
              --enable-optimizations \
              --with-lto \
              --enable-ipv6 \
              --with-system-expat \
              --with-dbmliborder=gdbm:ndbm \
              --with-system-ffi \
              --with-system-libmpdec \
              --enable-loadable-sqlite-extensions \
              --without-ensurepip

When Ctrl-C:

test_thousand (test.test_multiprocessing_forkserver.WithProcessesTestBarrier) ... ^CProcess Process-1305:
Traceback (most recent call last):
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/python/src/Python-3.8.4/Lib/test/_test_multiprocessing.py", line 1970, in _test_thousand_f
    barrier.wait()
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 610, in wait
    self._enter() # Block while the barrier drains.
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 631, in _enter
    self._cond.wait()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/synchronize.py", line 261, in wait
    return self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt
Process Process-1304:
Traceback (most recent call last):
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/python/src/Python-3.8.4/Lib/test/_test_multiprocessing.py", line 1970, in _test_thousand_f
    barrier.wait()
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 610, in wait
    self._enter() # Block while the barrier drains.
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 631, in _enter
    self._cond.wait()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/synchronize.py", line 261, in wait
    return self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt
Process Process-1306:
Traceback (most recent call last):
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/python/src/Python-3.8.4/Lib/test/_test_multiprocessing.py", line 1970, in _test_thousand_f
    barrier.wait()
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 610, in wait
    self._enter() # Block while the barrier drains.
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 631, in _enter
    self._cond.wait()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/synchronize.py", line 261, in wait
    return self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt
Process Process-1302:
Traceback (most recent call last):
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/python/src/Python-3.8.4/Lib/test/_test_multiprocessing.py", line 1970, in _test_thousand_f
    barrier.wait()
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 610, in wait
    self._enter() # Block while the barrier drains.
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 631, in _enter
    self._cond.wait()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/synchronize.py", line 261, in wait
    return self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt
Process Process-1303:
Traceback (most recent call last):
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/python/src/Python-3.8.4/Lib/test/_test_multiprocessing.py", line 1970, in _test_thousand_f
    barrier.wait()
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 610, in wait
    self._enter() # Block while the barrier drains.
  File "/build/python/src/Python-3.8.4/Lib/threading.py", line 631, in _enter
    self._cond.wait()
  File "/build/python/src/Python-3.8.4/Lib/multiprocessing/synchronize.py", line 261, in wait
    return self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing_forkserver
  Before: set()
  After:  {<weakref at 0x42d7274db0; to 'Process' at 0x42d608aaf0>, <weakref at 0x42d72746d0; to 'Process' at 0x42d608af10>, <weakref at 0x42d7274400; to 'Process' at 0x42d608a9a0>, <weakref at 0x42d7274d10; to 'Process' at 0x42d608abb0>, <weakref at 0x42d7274270; to 'Process' at 0x42d608a5e0>}

test_multiprocessing_fork passed in 1 min 46 sec

== Tests result: FAILURE, INTERRUPTED ==
Test suite interrupted by signal SIGINT.

----------
components: Library (Lib)
files: configure.output
messages: 374005
nosy: felixonmars
priority: normal
severity: normal
status: open
title: test_thousand and compileall hangs on riscv64
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49327/configure.output

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41346>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:57:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:57:40 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595249860.63.0.924437884967.issue41342@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5a2bac7fe0e7a2b67fd57c7a9176a50feed0d7a0 by Serhiy Storchaka in branch 'master':
bpo-41342: Convert int.__round__ to Argument Clinic (GH-21549)
https://github.com/python/cpython/commit/5a2bac7fe0e7a2b67fd57c7a9176a50feed0d7a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:56:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:56:58 +0000
Subject: [issue41343] Convert complex methods to Argument Clinic
In-Reply-To: <1595170189.2.0.291274613507.issue41343@roundup.psfhosted.org>
Message-ID: <1595249818.08.0.924274727978.issue41343@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41343>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:58:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:58:03 +0000
Subject: [issue41342] Convert int.__round__ to Argument Clinic
In-Reply-To: <1595162309.27.0.341065260309.issue41342@roundup.psfhosted.org>
Message-ID: <1595249883.72.0.932958311218.issue41342@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41342>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:56:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2020 12:56:38 +0000
Subject: [issue41334] Convert str(), bytes() and bytearray() to Argument Clinic
In-Reply-To: <1595084331.14.0.93182273048.issue41334@roundup.psfhosted.org>
Message-ID: <1595249798.8.0.609829279608.issue41334@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41334>
_______________________________________

From report at bugs.python.org  Mon Jul 20 09:10:14 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 13:10:14 +0000
Subject: [issue41336] Sporadic segfaults during zoneinfo object creation
 stopped using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595250614.85.0.445659654958.issue41336@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset add7cfc4c63f2ce2e8649906e6c8d902e95d8701 by Miss Islington (bot) in branch '3.9':
bpo-41336: Fix the error handling in zoneinfo_new_instance() (GH-21546)
https://github.com/python/cpython/commit/add7cfc4c63f2ce2e8649906e6c8d902e95d8701


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Mon Jul 20 09:48:46 2020
From: report at bugs.python.org (Michal Arbet)
Date: Mon, 20 Jul 2020 13:48:46 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595249688.36.0.272127617145.issue41345@roundup.psfhosted.org>
Message-ID: <CAKz7_JRtSNgNm8ufqsnKK_j18v6mp-SC-r=rU7tedTDHdckWkA@mail.gmail.com>


Michal Arbet <michal.arbet at ultimum.io> added the comment:

I'm using  Ubuntu 20.04 with dist apache2 and default settings :

michalarbet at pixla:~/work$ dpkg -l | grep apache
ii  apache2                                    2.4.41-4ubuntu3
          amd64        Apache HTTP Server
ii  apache2-bin                                2.4.41-4ubuntu3
          amd64        Apache HTTP Server (modules and other binary files)
ii  apache2-data                               2.4.41-4ubuntu3
          all          Apache HTTP Server (common files)
ii  apache2-utils                              2.4.41-4ubuntu3
          amd64        Apache HTTP Server (utility programs for web servers)
ii  libapache2-mod-php                         2:7.4+75
         all          server-side, HTML-embedded scripting language (Apache
2 module) (default)
ii  libapache2-mod-php7.4                      7.4.3-4ubuntu2.2
         amd64        server-side, HTML-embedded scripting language (Apache
2 module)

michalarbet at pixla:~/work$ uname -a
Linux pixla 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

When reproducing issue, be patient , you have to wait several iterations
before it will fail.
Some bug reports and discussion related to :

https://bugs.python.org/issue41345
https://github.com/psf/requests/issues/4664
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899406

po 20. 7. 2020 v 14:54 odes?latel Ilia Androshchuk <report at bugs.python.org>
napsal:

>
> Ilia Androshchuk <an7e at outlook.com> added the comment:
>
> Hi Michal,
> Which version of operating system and apache are you running?
> I'll try to reproduce
>
> ----------
> nosy: +an7e
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41345>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Mon Jul 20 09:55:23 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2020 13:55:23 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595253323.88.0.0463279863687.issue41100@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
pull_requests: +20709
pull_request: https://github.com/python/cpython/pull/21564

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Mon Jul 20 10:34:36 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Jul 2020 14:34:36 +0000
Subject: [issue39604] Document PyDateTimeAPI / PyDateTime_CAPI struct
In-Reply-To: <1581373301.32.0.397691619207.issue39604@roundup.psfhosted.org>
Message-ID: <1595255676.02.0.944716489874.issue39604@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39604>
_______________________________________

From report at bugs.python.org  Mon Jul 20 10:35:33 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Jul 2020 14:35:33 +0000
Subject: [issue30155] Add ability to get tzinfo from a datetime instance in C
 API
In-Reply-To: <1493047646.24.0.156322797242.issue30155@psf.upfronthosting.co.za>
Message-ID: <1595255733.4.0.222325730259.issue30155@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm going to rename this bug to focus only on issue #1. I think we can accept a PR adding two new macros. I would suggest calling them:
> - PyDateTime_DATE_GET_TZINFO
> - PyDateTime_TIME_GET_TZINFO

+1 for this.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Mon Jul 20 10:46:30 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Jul 2020 14:46:30 +0000
Subject: [issue41347] collections.deque.count performance enhancement
Message-ID: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Same situation as: https://bugs.python.org/issue39425

Mean +- std dev: [master_count] 946 ns +- 14 ns -> [ac_count] 427 ns +- 7 ns: 2.22x faster (-55%)

----------
assignee: corona10
components: Extension Modules
messages: 374010
nosy: corona10
priority: normal
severity: normal
status: open
title: collections.deque.count performance enhancement
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 10:46:56 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Jul 2020 14:46:56 +0000
Subject: [issue41347] collections.deque.count performance enhancement
In-Reply-To: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>
Message-ID: <1595256416.92.0.60169029559.issue41347@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Benchmark file

----------
Added file: https://bugs.python.org/file49328/bench_deque_count.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 10:49:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Jul 2020 14:49:08 +0000
Subject: [issue41347] collections.deque.count performance enhancement
In-Reply-To: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>
Message-ID: <1595256548.77.0.83333974115.issue41347@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +20710
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21566

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 11:02:56 2020
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Jul 2020 15:02:56 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1595257376.32.0.359732699781.issue41324@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I'm happy with the API, except that --with-system-libmpdec is naturally
broken.  So I've to release a new libmpdec, which I'd rather do soon
because I don't want to revisit this later.

Antoine has looked at the API.  If anyone else has requests or objections,
now would be a good time to raise concerns.  These two functions are
the centerpiece of the PR:

   mpd_uint128_triple_t PyDec_AsUint128Triple(const PyObject *dec)
   PyObject *PyDec_FromUint128Triple(const mpd_uint128_triple_t *triple)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Mon Jul 20 11:13:32 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 20 Jul 2020 15:13:32 +0000
Subject: [issue41347] collections.deque.count performance enhancement
In-Reply-To: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>
Message-ID: <1595258012.45.0.0582375442387.issue41347@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 11:21:21 2020
From: report at bugs.python.org (Unai Martinez)
Date: Mon, 20 Jul 2020 15:21:21 +0000
Subject: [issue41348] Support replacing global function pointers in a shared
 library
Message-ID: <1595258481.74.0.314238368417.issue41348@roundup.psfhosted.org>


New submission from Unai Martinez <unaimc at gmail.com>:

As discussed in https://stackoverflow.com/questions/62947076/replace-a-function-pointer-in-a-shared-library-with-ctypes, it seems currently not possible to replace an existing global variable in a shared library which contains a function pointer, with a callback defined in Python (through ctypes). However, it is possible to replace global variables of other types, such as `int`.

----------
components: ctypes
messages: 374013
nosy: Unai Martinez
priority: normal
severity: normal
status: open
title: Support replacing global function pointers in a shared library
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41348>
_______________________________________

From report at bugs.python.org  Mon Jul 20 11:38:15 2020
From: report at bugs.python.org (Tim Z)
Date: Mon, 20 Jul 2020 15:38:15 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
Message-ID: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>


New submission from Tim Z <timour1712 at gmail.com>:

It refuses to go full screen when I rotate screen 90? on mac

----------
components: macOS
messages: 374014
nosy: Tim Z, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: idle not going full screen when I rotate screen 90? on mac
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Mon Jul 20 11:46:27 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jul 2020 15:46:27 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595259987.66.0.35101449825.issue41349@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Mon Jul 20 12:09:49 2020
From: report at bugs.python.org (Nick Henderson)
Date: Mon, 20 Jul 2020 16:09:49 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
Message-ID: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>


New submission from Nick Henderson <nick.henderson at gmail.com>:

In both Python 3.8.3 and 3.9.0b3, using zipfile.Path to write a file in a context manager results in an attempt to write to the zip file after it is closed.

In Python 3.9.0b3:

import io
from zipfile import ZipFile, Path

def make_zip():
    """Make zip file and return bytes."""
    bytes_io = io.BytesIO()
    zip_file = ZipFile(bytes_io, mode="w")
    zip_path = Path(zip_file, "file-a")
    
    # use zipp.Path.open
    with zip_path.open(mode="wb") as fp:
        fp.write(b"contents of file-a")

    zip_file.close()

    data = bytes_io.getvalue()

    bytes_io.close()
    
    return data

zip_data = make_zip()
# Exception ignored in: <function ZipFile.__del__ at 0x10aceff70>
# Traceback (most recent call last):
#   File "/Users/nick/.pyenv/versions/3.9.0b3/lib/python3.9/zipfile.py", line 1807, in __del__
#     self.close()
#   File "/Users/nick/.pyenv/versions/3.9.0b3/lib/python3.9/zipfile.py", line 1824, in close
#     self.fp.seek(self.start_dir)
# ValueError: I/O operation on closed file.


In Python 3.8.3:

import io
from zipfile import ZipFile, Path

def make_zip():
    """Make zip file and return bytes."""
    bytes_io = io.BytesIO()
    zip_file = ZipFile(bytes_io, mode="w")
    zip_path = Path(zip_file, "file-a")
    
    # use zipp.Path.open
    with zip_path.open(mode="w") as fp:
        fp.write(b"contents of file-a")

    zip_file.close()

    data = bytes_io.getvalue()

    bytes_io.close()
    
    return data

zip_data = make_zip()
# Exception ignored in: <function ZipFile.__del__ at 0x10922e670>
# Traceback (most recent call last):
#   File "/Users/nick/.pyenv/versions/3.8.3/lib/python3.8/zipfile.py", line 1820, in __del__
#     self.close()
#   File "/Users/nick/.pyenv/versions/3.8.3/lib/python3.8/zipfile.py", line 1837, in close
#     self.fp.seek(self.start_dir)
# ValueError: I/O operation on closed file.

In the Python 3.8 example, mode="w" is used in the open method on zip_path.

----------
components: Library (Lib)
files: zippath_bug_39.py
messages: 374015
nosy: Nick Henderson
priority: normal
severity: normal
status: open
title: Use of zipfile.Path causes attempt to write after ZipFile is closed
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49329/zippath_bug_39.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Mon Jul 20 12:35:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 20 Jul 2020 16:35:16 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595262916.32.0.466925079899.issue41350@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:09:04 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 20 Jul 2020 17:09:04 +0000
Subject: [issue41321] Calculate timestamp is wrong in datetime.datetime
In-Reply-To: <1594977657.17.0.556958376615.issue41321@roundup.psfhosted.org>
Message-ID: <1595264944.87.0.240337135819.issue41321@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Hi dh4931 ? this is the expected result, assuming that the offsets changed between those two dates in your system local time.

The .timestamp() method returns an epoch time, which is the number of seconds since 1970-01-01T00:00:00 UTC, and so it is inherently timezone-aware. In Python 3, na?ve datetimes went from being "unitless datetimes" to representing "local datetimes", and in certain situations (like calling `.timestamp()`), your system's time zone is used.

If you want something that gives the number of seconds that has elapsed between two na?ve datetimes on the calendar and ignoring any daylight saving time transitions, subtract them directly to get a timedelta, then divide the result by a timedelta representing 1 second, like so:

    >>> (datetime.datetime(1986, 5, 4, 7, 13, 22) - datetime.datetime(1986, 5, 4, 0, 0, 0)) / datetime.timedelta(seconds=1)
    26002.0


    >>> (datetime.datetime(1986, 5, 2, 7, 13, 22) - datetime.datetime(1986, 5, 2, 0, 0, 0)) / datetime.timedelta(seconds=1)
    26002.0

----------
resolution:  -> not a bug
stage:  -> resolved
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41321>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:15:48 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 20 Jul 2020 17:15:48 +0000
Subject: [issue41254] Add to/from string methods to datetime.timedelta
In-Reply-To: <1594277218.28.0.16887324914.issue41254@roundup.psfhosted.org>
Message-ID: <1595265348.42.0.0519645557346.issue41254@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think it is unlikely that we'll want to experiment with this directly in CPython. I don't think a fixed format (other than the annoying one that you already get from calling `str` on a timedelta) is appropriate, but designing a modular format for time differences is more complicated than it might seem. I have had an open issue on dateutil to implement this for ages, but I haven't seen or come up with any proposals for a DSL for specifying timedelta formats: https://github.com/dateutil/dateutil/issues/444

It is annoyingly complicated to do this, and I'd rather it be tried out in other libraries with more flexibility to make breaking changes and a shorter release cadence. Dateutil is a good choice, but a clear and thorough proposal (or at least examples of this done well in other ecosystems we can crib from) is necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41254>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:19:24 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 20 Jul 2020 17:19:24 +0000
Subject: [issue41295] CPython 3.8.4 regression on __setattr__ in
 multiinheritance with metaclasses
In-Reply-To: <1594738636.27.0.745451783859.issue41295@roundup.psfhosted.org>
Message-ID: <1595265564.22.0.648559977805.issue41295@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Released.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41295>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:19:31 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 20 Jul 2020 17:19:31 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1595265571.32.0.0483738032274.issue41300@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Released.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:24:33 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 20 Jul 2020 17:24:33 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595265873.21.0.219761168946.issue39603@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 580fbb018fd0844806119614d752b41fc69660f9 by ?ukasz Langa in branch '3.8':
Python 3.8.5
https://github.com/python/cpython/commit/580fbb018fd0844806119614d752b41fc69660f9


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:29:59 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 20 Jul 2020 17:29:59 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595266199.47.0.830698767021.issue41288@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Is this fix causing the refleak build to fail on 3.8? See: https://buildbot.python.org/all/#/builders/484/builds/149

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:28:28 2020
From: report at bugs.python.org (Saumitra Verma)
Date: Mon, 20 Jul 2020 17:28:28 +0000
Subject: [issue41351] IDLE does not close the brackets and does not insert the
 closing quotes
Message-ID: <1595266108.62.0.449571815495.issue41351@roundup.psfhosted.org>


New submission from Saumitra Verma <saumitraverma04 at gmail.com>:

This feature must be added

----------
assignee: terry.reedy
components: IDLE
messages: 374021
nosy: Saumitra Verma, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE does not close the brackets and does not insert the closing quotes
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/issue41351>
_______________________________________

From report at bugs.python.org  Mon Jul 20 15:40:41 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 20 Jul 2020 19:40:41 +0000
Subject: [issue41014] warning: 'sqlite3_trace' is deprecated
In-Reply-To: <1592436367.99.0.294210468626.issue41014@roundup.psfhosted.org>
Message-ID: <1595274041.39.0.658916939622.issue41014@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

According to the SQLite documentation, sqlite3_trace() is deprecated. See https://sqlite.org/c3ref/profile.html

See also:
https://bugs.python.org/issue40318
https://github.com/python/cpython/pull/19581

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41014>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:00:24 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 20 Jul 2020 20:00:24 +0000
Subject: [issue41321] Calculate timestamp is wrong in datetime.datetime
In-Reply-To: <1594977657.17.0.556958376615.issue41321@roundup.psfhosted.org>
Message-ID: <1595275224.93.0.34217633269.issue41321@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41321>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:18:22 2020
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 20 Jul 2020 20:18:22 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1595276302.55.0.713676350952.issue29778@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I still don't understand why this is considered a Python security problem.  If the user can put a malicious "python3.dll" at some arbitrary spot in the filesystem (e.g. a USB flash drive), and fool Python.exe into loading it, then surely they could put an arbitrary executable at that same spot and launch it directly.  And that seems way more straightforward.  Why would anyone bother with this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:49:46 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:49:46 +0000
Subject: [issue27777] cgi.FieldStorage can't parse simple body with
 Content-Length and no Content-Disposition
In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>
Message-ID: <1595278186.83.0.214530045959.issue27777@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27777>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:50:15 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:50:15 +0000
Subject: [issue41139] cgi uses the locale encoding for log files
In-Reply-To: <1593257405.62.0.0746372218017.issue41139@roundup.psfhosted.org>
Message-ID: <1595278215.74.0.806660212489.issue41139@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41139>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:50:31 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:50:31 +0000
Subject: [issue41140] cgitb uses the locale encoding for log files
In-Reply-To: <1593257483.85.0.980733000785.issue41140@roundup.psfhosted.org>
Message-ID: <1595278231.45.0.779261873191.issue41140@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41140>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:50:53 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:50:53 +0000
Subject: [issue39727] cgi.parse() fatally attempts str.decode when handling
 multipart/form-data
In-Reply-To: <1582436056.52.0.172079709412.issue39727@roundup.psfhosted.org>
Message-ID: <1595278253.8.0.301374350813.issue39727@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39727>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:51:02 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:51:02 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1595278262.64.0.391807504904.issue9968@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:51:15 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:51:15 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1595278275.27.0.811677302455.issue10879@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:51:25 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:51:25 +0000
Subject: [issue1047397] cgitb failures
Message-ID: <1595278285.93.0.910962617797.issue1047397@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1047397>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:51:46 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:51:46 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1595278306.16.0.565525772616.issue38863@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:52:04 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:52:04 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1595278324.99.0.393853177743.issue24764@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24764>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:52:15 2020
From: report at bugs.python.org (Rhodri James)
Date: Mon, 20 Jul 2020 20:52:15 +0000
Subject: [issue21705] cgi.py: Multipart with more than one file is misparsed
In-Reply-To: <1402401424.17.0.414317354507.issue21705@psf.upfronthosting.co.za>
Message-ID: <1595278335.53.0.408758209628.issue21705@roundup.psfhosted.org>


Change by Rhodri James <rhodri.james65 at gmail.com>:


----------
nosy:  -Rhodri James

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21705>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:53:02 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 20 Jul 2020 20:53:02 +0000
Subject: [issue40744] Explicitly drop support for SQLite version < 3.7.3
In-Reply-To: <1590252054.91.0.549618457347.issue40744@roundup.psfhosted.org>
Message-ID: <1595278382.5.0.650475472843.issue40744@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

?ukasz, pinging you, since you are the release manager of 3.9.

Without PR 20909, 3.9 will be released without explicitly requiring SQLite 3.7.3 (setup.py looks for SQLite >= 3.7.2), compiling python 3.9 against SQLite 3.7.2 will fail at build time because of commit b9a0376, and it will also be possible to compile with SQLite 3.7.3 but run with pre SQLite 3.7.3 libraries, which could end up with a core dump.

With PR 20909, we explicitly state, in the docs, that SQLite 3.7.3 is required, and we explicitly check the SQLite version at configure time (setup.py), compile time (#ifdef => #error), and run time (if sqlite3_libversion_number() < ...) to prevent CPython from being configured, build, or run against unsupported SQLite versions.

I might be overestimating the severity of this issue, but I thought you would be interested this, as the release manager of 3.9 :)

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40744>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:58:26 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 20:58:26 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595278706.12.0.0355039379267.issue41327@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It already returns a non-zero exit code (should be (IIRC) 9009 to match the built-in cmd.exe result), and I've been trying to get the message added for at least a year now.

Unfortunately, I can only push it so far before it has to work through the Windows team's process, and then there's nobody to push it along. All that could really be done from outside is to organise a "why don't you fix the dev experience" spam campaign, but I'm not going to condone that ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Mon Jul 20 17:14:00 2020
From: report at bugs.python.org (Ziyi Wang)
Date: Mon, 20 Jul 2020 21:14:00 +0000
Subject: [issue41352] FileIO.readall() should raise "UnsupportedOperation"
 when in "w" mode
Message-ID: <1595279640.58.0.284092405556.issue41352@roundup.psfhosted.org>


New submission from Ziyi Wang <evnw at fb.com>:

Here are the two test cases: the one with FileIO.readall() fails

def testReadWithWritingMode(self):
    r, w = os.pipe()
    w = os.fdopen(w, "w")
    w.write("hello")
    w.close()
    with io.FileIO(r, mode="w") as f:
        with self.assertRaises(_io.UnsupportedOperation):
            f.read()

def testReadallWithWritingMode(self):
    r, w = os.pipe()
    w = os.fdopen(w, "w")
    w.write("hello")
    w.close()
    with io.FileIO(r, mode="w") as f:
        with self.assertRaises(_io.UnsupportedOperation):
            f.readall()

With FileIO.read() raises "UnsupportedOperation" in "w" mode, I expect FileIO.readall() do the same. But in fact FileIO.readall() does not check for readable and does not raise "UnsupportedOperation" in "w"mode.

I'm happy to write a pull request if you want.

----------
components: IO, Library (Lib)
messages: 374027
nosy: Ziyi Wang
priority: normal
severity: normal
status: open
title: FileIO.readall() should raise "UnsupportedOperation" when in "w" mode
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41352>
_______________________________________

From report at bugs.python.org  Mon Jul 20 17:23:52 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2020 21:23:52 +0000
Subject: [issue41352] FileIO.readall() should raise "UnsupportedOperation"
 when in "w" mode
In-Reply-To: <1595279640.58.0.284092405556.issue41352@roundup.psfhosted.org>
Message-ID: <1595280232.45.0.588162835771.issue41352@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20711
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21568

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41352>
_______________________________________

From report at bugs.python.org  Mon Jul 20 17:26:38 2020
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 20 Jul 2020 21:26:38 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595280398.14.0.0306976975101.issue41327@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

What would be the best channel to raise this issue to the Windows team from the outside? It does not need to be a spam campaign, but it?d be nice if we could direct the affected users somewhere instead of pypa/packaging-problems and various issue trackers, where the Windows team wouldn?t see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Mon Jul 20 17:27:31 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 20 Jul 2020 21:27:31 +0000
Subject: [issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized
 dllpath when embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1595280451.45.0.645775806256.issue29778@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I still don't understand why this is considered a Python security problem.
> If the user can put a malicious "python3.dll" at some arbitrary spot in 
> the filesystem (e.g. a USB flash drive), and fool Python.exe into loading
> it, then surely they could put an arbitrary executable at that same spot 
> and launch it directly.

What would be the point of adding an arbitrary executable in "C:\spam" or "D:\"? It's not in the system PATH, "App Paths", or any file-association template command. But if you can inject code into vulnerable processes that embed Python by simply creating "C:\DLLs\python3.dll", that seems like low-hanging fruit to me. Just wait for it to be run with administrator access, and then you can own the entire system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Mon Jul 20 18:01:48 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Jul 2020 22:01:48 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595282508.97.0.286077094441.issue38156@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
nosy: +benjamin.peterson
nosy_count: 1.0 -> 2.0
pull_requests: +20712
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21569

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Mon Jul 20 18:16:05 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 22:16:05 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595283365.28.0.17526665534.issue41327@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's already gone through the correct channels, so any other submissions will be duped by the triagers.

The best person to post at is me, but I've suffered enough for it :) I'm pushing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Mon Jul 20 18:22:01 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 22:22:01 +0000
Subject: [issue40932] subprocess docs should warn of shlex use on Windows
In-Reply-To: <1591735791.89.0.818565720729.issue40932@roundup.psfhosted.org>
Message-ID: <1595283721.88.0.754981625172.issue40932@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I wonder whether we should be more specific about the shells that shlex works for? Since WSL makes *sh (Bash, Dash, Sh, etc.) easily available on Windows, and I believe PowerShell on Linux keeps its own quoting rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40932>
_______________________________________

From report at bugs.python.org  Mon Jul 20 18:25:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 22:25:11 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595283911.93.0.468490366417.issue40741@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Python-3.8.4rc1 and Python-3.9.0b4 are still with SQLite-3.31.1.

Someone still had to send a PR to update the main build. It's not automatic, otherwise you wouldn't be able to reproduce older builds.

I'll do it now. It'll be in 3.8.6 and 3.9.0b6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 18:33:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 22:33:11 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595284391.54.0.37019754048.issue40741@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20713
pull_request: https://github.com/python/cpython/pull/21570

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:10:04 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 23:10:04 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595286604.24.0.736444240217.issue40741@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20714
pull_request: https://github.com/python/cpython/pull/21571

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:10:11 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jul 2020 23:10:11 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595286611.95.0.615587031443.issue40741@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20715
pull_request: https://github.com/python/cpython/pull/21572

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:09:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 23:09:49 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595286589.68.0.380783953064.issue40741@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 84761c3cc4bac31d471e371c53a338686d4b0241 by Steve Dower in branch 'master':
bpo-40741: Update Windows build to include SQLite 3.32.3 (GH-21570)
https://github.com/python/cpython/commit/84761c3cc4bac31d471e371c53a338686d4b0241


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:17:21 2020
From: report at bugs.python.org (Ilia Androshchuk)
Date: Mon, 20 Jul 2020 23:17:21 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595245426.33.0.812684814237.issue41345@roundup.psfhosted.org>
Message-ID: <1595287041.66.0.272263129261.issue41345@roundup.psfhosted.org>


Ilia Androshchuk <an7e at outlook.com> added the comment:

Hi, Michal
It took a lot of time, but I achieved exactly the same behavior.

My Traceback :

DEBUG:urllib3.connectionpool:Resetting dropped connection: localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "POST / HTTP/1.1" 200 3138
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 421, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 416, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.8/http/client.py", line 1332, in getresponse
    response.begin()
  File "/usr/lib/python3.8/http/client.py", line 303, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.8/http/client.py", line 272, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 719, in urlopen
    retries = retries.increment(
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 400, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "/usr/lib/python3/dist-packages/six.py", line 702, in reraise
    raise value.with_traceback(tb)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 421, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 416, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.8/http/client.py", line 1332, in getresponse
    response.begin()
  File "/usr/lib/python3.8/http/client.py", line 303, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.8/http/client.py", line 272, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test1.py", line 14, in <module>
    s.post('http://localhost', data={counter:txt})
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 581, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

I'm using same dist and settings:

lerfi at UbuntuVM:~/work/psf/41345$ uname -a
Linux UbuntuVM 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
erfi at UbuntuVM:~/work/psf/41345$ dpkg -l | grep apache
ii  apache2                                    2.4.41-4ubuntu3                       amd64        Apache HTTP Server
ii  apache2-bin                                2.4.41-4ubuntu3                       amd64        Apache HTTP Server (modules and other binary files)
ii  apache2-data                               2.4.41-4ubuntu3                       all          Apache HTTP Server (common files)
ii  apache2-utils                              2.4.41-4ubuntu3                       amd64        Apache HTTP Server (utility programs for web servers)
pip3 requests==2.22.0

it looks like there's a problem with this urllib3 package

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:20:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Jul 2020 23:20:13 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595287213.48.0.959885512239.issue40741@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Closing this one now.

Let's use a new issue next time there's a need to update SQLite.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:45:01 2020
From: report at bugs.python.org (ramalho)
Date: Mon, 20 Jul 2020 23:45:01 +0000
Subject: [issue40979] typing module docs: keep text, add subsections
In-Reply-To: <1592164571.1.0.235029301981.issue40979@roundup.psfhosted.org>
Message-ID: <1595288701.96.0.115041213255.issue40979@roundup.psfhosted.org>


ramalho <luciano at ramalho.org> added the comment:

This is my proposal for sections to replace the existing "Classes, functions, and decorators" section. The names are sorted within each section.

# Special typing primitives	
	Any
	Callable
	ClassVar
	ForwardRef
	Generic
	Literal
	NamedTuple
	NewType
	NoReturn
	Optional
	Type
	TypedDict
	TypeVar
	Union

# Generic ABCs	
	AbstractSet
	AsyncContextManager
	AsyncGenerator
	AsyncIterable
	AsyncIterator
	Awaitable
	ByteString
	Collection
	Container
	ContextManager
	Coroutine
	Generator
	Hashable
	io.IO
	io.BytesIO
	io.TextIO
	ItemsView
	Iterable
	Iterator
	KeysView
	Mapping
	MappingView
	MutableMapping
	MutableSequence
	MutableSet
	re.Pattern
	re.Match
	Sequence
	Sized
	ValuesView	

# Generic Concrete Collections	
	ChainMap
	Counter
	DefaultDict
	Deque
	Dict
	FrozenSet
	List
	OrderedDict
	Set
	Tuple

# Structural checks, a.k.a. protocols.	
	Reversible
	SupportsAbs
	SupportsBytes
	SupportsComplex
	SupportsFloat
	SupportsInt
	SupportsRound	

# Functions and decorators	
	cast
	final
	get_args
	get_origin
	get_type_hints
	no_type_check
	no_type_check_decorator
	overload
	runtime_checkable
	type_check_only
	
# Aliases and constants	
	AnyStr
	Text
	TYPE_CHECKING

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40979>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:49:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2020 23:49:40 +0000
Subject: [issue41347] collections.deque.count performance enhancement
In-Reply-To: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>
Message-ID: <1595288980.43.0.651492399818.issue41347@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would rather not do this.   It optimizes for the uncommon case where all the objects are identical.  The common case is slightly worse off because the identity test is performed twice, once before the call to Py_RichCompareBool() and again inside it.  Also, the PR adds a little clutter which obscures the business logic.  

Another thought, micro-benchmarks on the identity tests require some extra care because they are super sensitive to branch prediction failures (See https://stackoverflow.com/questions/11227809 ).  A more realistic dataset would be:

  x = 12345
  data = [x] * 100 + list(range(500))
  random.shuffle(data)
  data.count(x)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:09:59 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jul 2020 00:09:59 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595290199.41.0.40460592641.issue40741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f599f9ea3cdcf280cdf3a72272148895d8fcb3a4 by Miss Islington (bot) in branch '3.8':
bpo-40741: Update Windows build to include SQLite 3.32.3 (GH-21570)
https://github.com/python/cpython/commit/f599f9ea3cdcf280cdf3a72272148895d8fcb3a4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:10:35 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jul 2020 00:10:35 +0000
Subject: [issue40741] Upgrade to SQLite v3.32 in Windows and macOS builds
In-Reply-To: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>
Message-ID: <1595290235.74.0.513821841475.issue40741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d6ba8c8e16b844e2c21bfe96217dd62dc50e9014 by Miss Islington (bot) in branch '3.9':
bpo-40741: Update Windows build to include SQLite 3.32.3 (GH-21570)
https://github.com/python/cpython/commit/d6ba8c8e16b844e2c21bfe96217dd62dc50e9014


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40741>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:22:09 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 21 Jul 2020 00:22:09 +0000
Subject: [issue41283] The parameter name for imghdr.what in the documentation
 is wrong
In-Reply-To: <1594545631.96.0.481890798822.issue41283@roundup.psfhosted.org>
Message-ID: <1595290929.86.0.802676276506.issue41283@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:


New changeset 5241e189e77972d3a07acbbb3f0c0cbc2aeeb681 by Ammar Askar in branch 'master':
bpo-41283: Fix mismatched argument name for imghdr.what (GH-21501)
https://github.com/python/cpython/commit/5241e189e77972d3a07acbbb3f0c0cbc2aeeb681


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41283>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:24:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jul 2020 00:24:16 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595291056.07.0.915030903972.issue41349@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Windows, right clicking on the desktop produces a context menu with Display Settings.  The dialog has an Orientation pulldown menu with the 4 choices.  Without actually rotating my screen, I clicked Portrait and managed to start IDLE and click the full-screen box.  It worked.

I could not find a similar option on my Macbook.  Since the screen is attached to the keyboard, it would be pretty useless.

IDLE has some control over whether the full screen button appears on the window title bar, but has nothing to do with what happens when you click it.  So this is almost certainly a python-on-macOS installation issue or more likely a tck/tk-on-macOS issue.  (One could eliminate IDLE for sure with a minimal tkinter program creating an empty window: "import tkinter; tkinter.Tk()".  If that worked, as a Text widget.

Kevin, is not maximizing in portrait mode a known issue with tk on macOS?

----------
components:  -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:47:38 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Jul 2020 00:47:38 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1595292458.89.0.995219966338.issue9694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll put together a patch this week to address the terminology problem.

----------
assignee: docs at python -> rhettinger
priority: normal -> low
versions: +Python 3.10, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:50:28 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 21 Jul 2020 00:50:28 +0000
Subject: [issue41283] The parameter name for imghdr.what in the documentation
 is wrong
In-Reply-To: <1594545631.96.0.481890798822.issue41283@roundup.psfhosted.org>
Message-ID: <1595292628.25.0.478266071242.issue41283@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +20716
pull_request: https://github.com/python/cpython/pull/21573

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41283>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:55:15 2020
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jul 2020 00:55:15 +0000
Subject: [issue40979] typing module docs: keep text, add subsections
In-Reply-To: <1592164571.1.0.235029301981.issue40979@roundup.psfhosted.org>
Message-ID: <1595292915.95.0.964804760799.issue40979@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +20717
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21574

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40979>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:10:15 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jul 2020 01:10:15 +0000
Subject: [issue30044] shutil.copystat should (allow to) copy ownership,
 and other attributes
In-Reply-To: <1491925353.8.0.782070431072.issue30044@psf.upfronthosting.co.za>
Message-ID: <1595293815.85.0.525081790359.issue30044@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Since the need to copy file ownership is common, I think there could
> be space for a new copy3() function which copies ownership + extended
> attributes (where possible).

FYI, Windows and POSIX have significantly different concepts about file (object) ownership. In Windows:

    * Any type of SID can be set as the owner, such as a user, global
      group, local group, well-known group, domain, or logon session. All
      of these SID types, except for user SIDs, are commonly set in the
      groups of a token. Also, the token user is not limited to just users.
      It's commonly set to a well-known group such as SYSTEM, LOCAL
      SERVICE, or NETWORK SERVICE.

    * The effective access token of a thread is granted owner rights to
      an object if the token user or any of the token's enabled groups is
      the owner of the object. For example, if an object is owned by the
      "BUILTIN\Users" local group, then all access tokens for standard-user
      logons will be granted owner rights as long as they have the
      "BUILTIN\Users" group enabled, which it is by default.
      
    * If not set explicitly via "OWNER RIGHTS" (i.e. S-1-3-4), the 
      owner is implicitly granted the READ_CONTROL right to query the
      object security and the WRITE_DAC right to modify the object's
      resource attributes and discretionary access-control list. As 
      long as these rights are granted implicitly, they cannot be
      denied by deny access-control entries. However, implicit owner
      rights may be denied if an object has an implicit (by object 
      type) or explicit (by label) no-read-up or no-write-up mandatory
      policy, and the token's integrity level is less than that of the
      object.

    * An explicit "OWNER RIGHTS" entry can be set in the discretionary
      access control list in order to override the implicit owner rights.
      This is not the same as setting owner rights in POSIX, since other
      ACL entries may grant or deny rights. Given the canonical priority 
      of deny access-control entries and also mandatory access control
      based on the integrity level of the object vs the token, granting
      explicit access to "OWNER RIGHTS" does not necessarily ensure the
      owner will even be granted at least the desired access in all
      contexts. Also, unlike the implicit case, if an "OWNER RIGHTS"
      entry grants READ_CONTROL and/or WRITE_DAC access, either right 
      may be denied by deny access-control entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30044>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:11:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jul 2020 01:11:13 +0000
Subject: [issue41351] IDLE does not close the brackets and does not insert the
 closing quotes
In-Reply-To: <1595266108.62.0.449571815495.issue41351@roundup.psfhosted.org>
Message-ID: <1595293873.68.0.832715122411.issue41351@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please don't state opinions as facts.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Idle: Auto insertion of the closing parens, brackets, and braces
versions:  -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/issue41351>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:36:03 2020
From: report at bugs.python.org (Luciano Ramalho)
Date: Tue, 21 Jul 2020 01:36:03 +0000
Subject: [issue40979] typing module docs: keep text, add subsections
In-Reply-To: <1592164571.1.0.235029301981.issue40979@roundup.psfhosted.org>
Message-ID: <1595295363.81.0.160604868263.issue40979@roundup.psfhosted.org>


Luciano Ramalho <luciano at ramalho.org> added the comment:

Reviewers, besides adding section titles and reordering the entries, I made only these changes to the text:

- entry for IO, TextIO, BinaryIO: added sentence "These types are in the ``typing.io`` namespace."

- entry for Pattern, Match: added sentence "These types are in the ``typing.re`` namespace."

- entry for TypedDict: removed the words "equivalent to" from the sentence "At runtime it is <equivalent to> a plain dict."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40979>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:59:17 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 21 Jul 2020 01:59:17 +0000
Subject: [issue41353] Indicate supported sound header formats
Message-ID: <1595296757.63.0.289277741355.issue41353@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

The documentation for the sndhdr module does not have supported file formats. Something like below could help:

+------------+------------------------------------+
| Value      | Sound header format                |
+============+====================================+
| ``'aifc'`` | Compressed Audio Interchange Files |
+------------+------------------------------------+
| ``'aiff'`` | Audio Interchange Files            |
+------------+------------------------------------+
| ``'au'``   | AU Files                           |
+------------+------------------------------------+
| ``'hcom'`` | HCOM Files                         |
+------------+------------------------------------+
| ``'sndr'`` | SNDR Files                         |
+------------+------------------------------------+
| ``'sndt'`` | SNDT Files                         |
+------------+------------------------------------+
| ``'voc'``  | VOC Files                          |
+------------+------------------------------------+
| ``'wav'``  | WAV Files                          |
+------------+------------------------------------+
| ``'8svx'`` | 8SVX Files                         |
+------------+------------------------------------+
| ``'sb'``   | SB Files                           |
+------------+------------------------------------+
| ``'ub'``   | UB Files                           |
+------------+------------------------------------+
| ``'ul'``   | uLAW Audio Files                   |
+------------+------------------------------------+

----------
messages: 374047
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Indicate supported sound header formats

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41353>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:59:49 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 21 Jul 2020 01:59:49 +0000
Subject: [issue41353] Indicate supported sound header formats
In-Reply-To: <1595296757.63.0.289277741355.issue41353@roundup.psfhosted.org>
Message-ID: <1595296789.73.0.867985040523.issue41353@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41353>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:59:51 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jul 2020 01:59:51 +0000
Subject: [issue41347] collections.deque.count performance enhancement
In-Reply-To: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>
Message-ID: <1595296791.91.0.0873850748224.issue41347@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> I would rather not do this.

I would not like to say this change should be applied ;)
I found this point during I converting deque methods by using 
Argument Clinic(I will ping you later ;)


https://bugs.python.org/issue39425 was applied since PyObject_RichCompareBool requires reference counting and it caused performance regression. 

Know I remember, why we applied this micro-optimization.

So my conclusion is that don't apply this change.
We don't have to apply this change since PyObject_RichCompareBool does not cause a performance regression.

Thank you for your comment, Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 22:00:20 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 21 Jul 2020 02:00:20 +0000
Subject: [issue41353] Indicate supported sound header formats
In-Reply-To: <1595296757.63.0.289277741355.issue41353@roundup.psfhosted.org>
Message-ID: <1595296820.36.0.66387306452.issue41353@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +20719
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41353>
_______________________________________

From report at bugs.python.org  Mon Jul 20 22:00:29 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jul 2020 02:00:29 +0000
Subject: [issue41347] collections.deque.count performance enhancement
In-Reply-To: <1595256390.45.0.494229030052.issue41347@roundup.psfhosted.org>
Message-ID: <1595296829.13.0.82420742819.issue41347@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41347>
_______________________________________

From report at bugs.python.org  Mon Jul 20 22:28:12 2020
From: report at bugs.python.org (Lawrence D'Anna)
Date: Tue, 21 Jul 2020 02:28:12 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595298492.28.0.522029719027.issue41100@roundup.psfhosted.org>


Change by Lawrence D'Anna <lawrence_danna at apple.com>:


----------
pull_requests: +20720
pull_request: https://github.com/python/cpython/pull/21576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Mon Jul 20 22:59:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jul 2020 02:59:16 +0000
Subject: [issue18875] Idle: Auto insertion of the closing parens, brackets,
 and braces
In-Reply-To: <1377777498.6.0.468253349222.issue18875@psf.upfronthosting.co.za>
Message-ID: <1595300356.15.0.884664435333.issue18875@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I found this in Notepad++ under Settings -> Preferences -> Auto-completion -> Auto-insert with separate checkboxes for (, {, [, ', ", html/xml tags, and up to 3 custom pairs.  Way too elaborate for IDLE.  The only question to me is whether to have just one option for all 5 openers or separate option to complete ([{ versus quotes.

Concerns: a) matching triple quotes is a bit baroque, though possible the most useful part of the feature; b) except for completing tripple quotes, no keystrokes are saved, and then only if one used End to skip three chars at once.  On the other hand, at least some people who have use the feather elsewhere consider it a net win.

Implementation notes: 1. IDLE editors uses two mechanisms to respond to keystrokes.  The delegator mechanism checks all keystrokes and responds to some.  IDLE otherwise binds keystrokes to event-handlers or to pseudoevent bound to event-handlers.  Perhaps these could be unified and made more efficient.

2. In the meanwhile... Menu items are bound to pseudoevents, along with corresponding hot heys.  This issue will *not* add a menu entry "Add matching closer".  So the openers can be bound directly to event handlers that look at the opener.

----------
versions: +Python 3.10 -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18875>
_______________________________________

From report at bugs.python.org  Mon Jul 20 23:01:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Jul 2020 03:01:50 +0000
Subject: [issue40979] typing module docs: keep text, add subsections
In-Reply-To: <1592164571.1.0.235029301981.issue40979@roundup.psfhosted.org>
Message-ID: <1595300510.42.0.581337666246.issue40979@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This organization makes good sense to me.   Hopefully, we can get Guido and Ivan to take a look at it.

----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40979>
_______________________________________

From report at bugs.python.org  Mon Jul 20 23:19:45 2020
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 21 Jul 2020 03:19:45 +0000
Subject: [issue40932] subprocess docs should warn of shlex use on Windows
In-Reply-To: <1591735791.89.0.818565720729.issue40932@roundup.psfhosted.org>
Message-ID: <1595301585.61.0.760475528298.issue40932@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Hmm, it'd be hard to enumerate them all. The module does say, "...simple syntaxes resembling that of the Unix shell" but that's it.

Distinguishing at the OS level for shlex does seem a bit weird given the existence of WSL and non-compliant shells on Linux like xonsh. I think it'd be nice if we could be a bit more specific on whats supported, maybe it covers all POSIX compliant shells?

For the subprocess warning I think it's fine to talk about the OS since it looks like the shell used are hard-coded in:

* https://github.com/python/cpython/blob/5241e189e77972d3a07acbbb3f0c0cbc2aeeb681/Lib/subprocess.py#L1403-L1407
* https://github.com/python/cpython/blob/5241e189e77972d3a07acbbb3f0c0cbc2aeeb681/Lib/subprocess.py#L1680-L1686

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40932>
_______________________________________

From report at bugs.python.org  Tue Jul 21 00:25:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jul 2020 04:25:13 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1595305513.74.0.500186254845.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The fix is in both 3.8.5 and 3.9.0b5, both released today.
"print('eyes ?? snake ?')", for instance, in the editor, can be saved and run.  (Note that astral chars like the snake disrupt editing a bit, but once there, can be saved and will print.

?ukasz, thanks for getting this in.  I am leaving this open to add tests, but will remove you as nosy.

----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Tue Jul 21 00:25:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jul 2020 04:25:31 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1595305531.62.0.303036947573.issue41300@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Tue Jul 21 00:43:59 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 21 Jul 2020 04:43:59 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1595306639.67.0.882692550459.issue10879@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Tue Jul 21 01:54:50 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 21 Jul 2020 05:54:50 +0000
Subject: [issue41331] Sphinx can't find asdl.py when not started from the Doc/
 directory
In-Reply-To: <1595060795.82.0.837754146284.issue41331@roundup.psfhosted.org>
Message-ID: <1595310890.2.0.23480820399.issue41331@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41331>
_______________________________________

From report at bugs.python.org  Tue Jul 21 02:01:51 2020
From: report at bugs.python.org (Lawrence D'Anna)
Date: Tue, 21 Jul 2020 06:01:51 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595311311.98.0.190689218062.issue41100@roundup.psfhosted.org>


Change by Lawrence D'Anna <lawrence_danna at apple.com>:


----------
pull_requests: +20721
pull_request: https://github.com/python/cpython/pull/21577

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Tue Jul 21 03:01:17 2020
From: report at bugs.python.org (Paul Moore)
Date: Tue, 21 Jul 2020 07:01:17 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595314877.84.0.860138706209.issue41327@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Understood that these would be duplicates, and I certainly don't want to put more pressure on you, but I think there would still be value in having a known reporting channel for people to say "I am also affected by this":

* MS Developers get a more objective feel for the scale of the issue.
* Users who report the issue can track progress (they will presumably get told *what* their report is a duplicate of, and can follow the underlying issue).
* Python package developers have something definite that they can offer to users.

My suspicion here is that MS simply doesn't have a user-visible support channel for the Store Python stubs, which is why we've ended up discussing this here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Tue Jul 21 03:29:03 2020
From: report at bugs.python.org (Christof Hanke)
Date: Tue, 21 Jul 2020 07:29:03 +0000
Subject: [issue41354] filecmp.cmp documentation does not match actual code
Message-ID: <1595316543.83.0.558279011146.issue41354@roundup.psfhosted.org>


New submission from Christof Hanke <christof.hanke at mpcdf.mpg.de>:

help(filecmp.cmp) says:

"""
cmp(f1, f2, shallow=True)
    Compare two files.
    
    Arguments:
    
    f1 -- First file name
    
    f2 -- Second file name
    
    shallow -- Just check stat signature (do not read the files).
               defaults to True.
    
    Return value:
    
    True if the files are the same, False otherwise.
    
    This function uses a cache for past comparisons and the results,
    with cache entries invalidated if their stat information
    changes.  The cache may be cleared by calling clear_cache().
"""

However, looking at the code, the shallow-argument is taken only into account if the signatures are the same:
"""
    s1 = _sig(os.stat(f1))
    s2 = _sig(os.stat(f2))
    if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG:
        return False
    if shallow and s1 == s2:
        return True
    if s1[1] != s2[1]:
        return False

    outcome = _cache.get((f1, f2, s1, s2))
    if outcome is None:
        outcome = _do_cmp(f1, f2)
        if len(_cache) > 100:      # limit the maximum size of the cache
            clear_cache()
        _cache[f1, f2, s1, s2] = outcome
    return outcome
"""

Therefore, if I call cmp with shallow=True and the stat-signatures differ, 
cmp actually does a "deep" compare.
This "deep" compare however does not check the stat-signatures.

Thus I propose follwing patch:
cmp always checks the "full" signature.
return True if shallow and above test passed.
It does not make sense to me that when doing a "deep" compare, that only the size 
is compared, but not the mtime. 


--- filecmp.py.orig     2020-07-16 12:00:57.000000000 +0200
+++ filecmp.py  2020-07-16 12:00:30.000000000 +0200
@@ -52,10 +52,10 @@
     s2 = _sig(os.stat(f2))
     if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG:
         return False
-    if shallow and s1 == s2:
-        return True
-    if s1[1] != s2[1]:
+    if s1 != s2:
         return False
+    if shallow:
+        return True
 
     outcome = _cache.get((f1, f2, s1, s2))
     if outcome is None:

----------
components: Library (Lib)
messages: 374054
nosy: chanke
priority: normal
severity: normal
status: open
title: filecmp.cmp documentation does not match actual code
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41354>
_______________________________________

From report at bugs.python.org  Tue Jul 21 04:47:35 2020
From: report at bugs.python.org (Hugo)
Date: Tue, 21 Jul 2020 08:47:35 +0000
Subject: [issue4928] tempfile.NamedTemporaryFile: automatic cleanup by OS
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1595321255.73.0.936917974817.issue4928@roundup.psfhosted.org>


Hugo <hugo at barrera.io> added the comment:

It would seem that the main issue here lies in the documentation not being  obvious enough for some of us. If you're familiar with lower level OS APIs, it might be clear, but as an app developer, some things slip by.

The key difference is that TemporaryFile will be erased properly (at least on Linux) even if the process gets a SIGKILL, while NamedTemporaryFile will linger (which fills up my disk every few weeks/months).

As an application developer, this difference is super important to me (I hope I'm not the only one). Would a PR that mentions this explicitly in the docs be an acceptable solution here?

----------
nosy: +WhyNotHugo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Tue Jul 21 05:05:58 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jul 2020 09:05:58 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595322358.38.0.219216200656.issue41327@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> there would still be value in having a known reporting channel

Windows 10 has a "Feedback Hub" to report problems and search for existing feedback that's similar. You could report a problem with the "AppInstaller" app. In this case, the app execution alias targets "AppInstallerPythonRedirector.exe". This is a GUI program, so CMD won't wait on it and set %errorlevel% if run from an interactive prompt -- not unless one uses `start /w` to force it to wait. (Sidebar: CMD determines that it's a GUI program by querying the PEB address and reading the process PEB via ReadProcessMemory... hack-o-rama.) 

IMO, the installer-redirector in this case should be a console application that prints a message to stdout to inform the user that it's opening the store to install Python. If it fails, it should print an error message to stderr and return a non-zero exit status.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Tue Jul 21 05:26:27 2020
From: report at bugs.python.org (Christof Hanke)
Date: Tue, 21 Jul 2020 09:26:27 +0000
Subject: [issue41354] filecmp.cmp documentation does not match actual code
In-Reply-To: <1595316543.83.0.558279011146.issue41354@roundup.psfhosted.org>
Message-ID: <1595323587.56.0.103035062328.issue41354@roundup.psfhosted.org>


Change by Christof Hanke <christof.hanke at mpcdf.mpg.de>:


----------
keywords: +patch
pull_requests: +20722
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21580

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41354>
_______________________________________

From report at bugs.python.org  Tue Jul 21 05:28:04 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 21 Jul 2020 09:28:04 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
Message-ID: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The code for os.link() seems to ignore follow_symlinks when the linkat(2) function is not available on the platform, which results in unexpected behaviour when "follow_symlinks" is false.

----------
components: Extension Modules
messages: 374057
nosy: ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: os.link(..., follow_symlinks=False) without linkat(3)
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:00:36 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 21 Jul 2020 10:00:36 +0000
Subject: [issue41356] Convert bool.__new__ to argument clinic
Message-ID: <1595325636.21.0.753393963516.issue41356@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Benchmarked on my machine (Windows 10):

.\python.bat -m pyperf timeit -s "from collections import deque; x = [[], [1]] * 1_000_000" "deque(map(bool, x), maxlen=0)"
    
    --- Win32 build configuration ---
    Master:             105 ms +- 2 ms
    With this change:  88.2 ms +- 2.1 ms

    --- x64 build configuration ---
    Master:            80.2 ms +- 1.3 ms
    With this change:  74.2 ms +- 0.5 ms

----------
components: Argument Clinic
messages: 374058
nosy: Dennis Sweeney, larry
priority: normal
severity: normal
status: open
title: Convert bool.__new__ to argument clinic
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41356>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:01:17 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 21 Jul 2020 10:01:17 +0000
Subject: [issue41356] Convert bool.__new__ to argument clinic
In-Reply-To: <1595325636.21.0.753393963516.issue41356@roundup.psfhosted.org>
Message-ID: <1595325677.95.0.139869945016.issue41356@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
keywords: +patch
pull_requests: +20723
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41356>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:15:48 2020
From: report at bugs.python.org (Tim Z)
Date: Tue, 21 Jul 2020 10:15:48 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595326548.82.0.199218178335.issue41349@roundup.psfhosted.org>


Tim Z <timour1712 at gmail.com> added the comment:

I have 2nd screen that rotate to portrait. Is there a way to launch "import tkinter; tkinter.Tk()" at idle start? Or I better wait the next update?
It's not related but...
  ...why idle3.8 don't have cut/copy/paste on right click? (I mean the paste is broken when you paste-replace selected text). What's up with this one https://bugs.python.org/issue38946 ?
Is there a shortage of volunteers ? Or it's all macOS fault?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:31:29 2020
From: report at bugs.python.org (Jendrik Weise)
Date: Tue, 21 Jul 2020 10:31:29 +0000
Subject: [issue41357] pathlib.Path.resolve incorrect os.path equivalent
Message-ID: <1595327489.48.0.566751491612.issue41357@roundup.psfhosted.org>


New submission from Jendrik Weise <jewe37 at gmail.com>:

According to the table at the bottom of the pathlib documentation Path.resolve() is equivalent to os.path.abspath(path). In contrast to the latter Path.resolve() does follow symlinks though, making it more similar to os.path.realpath(path).

----------
assignee: docs at python
components: Documentation
messages: 374060
nosy: Jendrik Weise, docs at python
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve incorrect os.path equivalent
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/issue41357>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:37:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jul 2020 10:37:12 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595327832.57.0.0794776557834.issue41349@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I meant to run 'import tkinter; tkinter.Tk()' directly in python, without IDLE involved, in your portrait window.  Do that by running terminal in the portrait window.  Then try to maximize.

Yes we need more volunteers, but #38946 is an issue between macOS Catalina and tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:39:11 2020
From: report at bugs.python.org (Matthew Davis)
Date: Tue, 21 Jul 2020 10:39:11 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1595327951.77.0.463601941212.issue29056@roundup.psfhosted.org>


Matthew Davis <ubuntu.one at mdavis.xyz> added the comment:

The documentation says "you will have to clear the cached value"

What does that mean? How do I clear the cached value? Is there a flush function somewhere? Do I `del` the attribute? Set the attribute to None?

The documentation as it stands today does not provide enough detail about this workaround.

----------
nosy: +matt-davis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Tue Jul 21 06:39:57 2020
From: report at bugs.python.org (hap)
Date: Tue, 21 Jul 2020 10:39:57 +0000
Subject: [issue41358] Unable to uninstall Python launcher using command line
Message-ID: <1595327997.84.0.414162156618.issue41358@roundup.psfhosted.org>


New submission from hap <ahmedparvez321 at gmail.com>:

Trying to create a command line keeping the following in mind, and my script is python-3.8.4.exe" /quiet InstallLauncherAllUsers=0 Include_pip=1 Include_tcltk=1 Include_test=1 PrependPath=1
1. Python installs in user profile
2. Install pip as a part of installation
All good here. 
So, my script installs python and also installs Python Launcher.

So far so good!

The problem is, when uninstall python i use command "python-3.8.4.exe" /quiet /uninstall, it does uninstall python, but this does not uninstall Python Launcher. Therefore, i call msiexec.exe /x {339192BE-2520-4C34-89DF-81CF98EB7E6C} /qn+ and it does remove all components from %localappdata%\Package Cache folder, except that it still keeps launcher.msi (588kb) and also entry in appwiz.cpl (around 7.15 MB).

What i am trying to achieve is,
1. If user wants to uninstall Python, it should uninstall python and python launcher because i don't want to leave away any installer files which an contribute to my system space.

I have gone through many links with failed help. Any suggestion to save my 7.2 MB space is greatly appreciated.

----------
components: Installation
messages: 374063
nosy: ahmedparvez321 at gmail.com
priority: normal
severity: normal
status: open
title: Unable to uninstall Python launcher using command line
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41358>
_______________________________________

From report at bugs.python.org  Tue Jul 21 07:22:13 2020
From: report at bugs.python.org (Tim Z)
Date: Tue, 21 Jul 2020 11:22:13 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595330533.44.0.708847645021.issue41349@roundup.psfhosted.org>


Tim Z <timour1712 at gmail.com> added the comment:

It works even after restart. I thought I had to run it after each restart I did it in idle only once.
So no need to do it again in python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Tue Jul 21 07:27:32 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 21 Jul 2020 11:27:32 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595330852.58.0.119222868123.issue41100@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
pull_requests: +20724
pull_request: https://github.com/python/cpython/pull/21583

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Tue Jul 21 07:46:47 2020
From: report at bugs.python.org (Krzysiek)
Date: Tue, 21 Jul 2020 11:46:47 +0000
Subject: [issue41359] argparse mutually exclusive group does not exclude in
 some cases
Message-ID: <1595332007.75.0.283126282834.issue41359@roundup.psfhosted.org>


New submission from Krzysiek <krzychdid at interia.pl>:

The documentation for `ArgumentParser.add_mutually_exclusive_group` states: "argparse will make sure that only one of the arguments in the mutually exclusive group was present on the command line".

This is not the case in certain circumstances:

```python
import argparse

parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group()
group.add_argument('-a')
group.add_argument('-b', nargs='?')

parser.parse_args('-a a -b'.split())
```

The above code does not produce any error, even though both exclusive arguments are present.

My guess is that the check for mutual exclusion is not done during processing of each command line argument, but rather afterwards. It seems the check only ensures at most one argument from group is not `None`.

The issue exists at least on Python 2.7.13, 3.6, 3.7.5, 3.8, and 3.10.

----------
components: Library (Lib)
messages: 374065
nosy: kkarbowiak
priority: normal
severity: normal
status: open
title: argparse mutually exclusive group  does not exclude in some cases
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41359>
_______________________________________

From report at bugs.python.org  Tue Jul 21 08:21:54 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Jul 2020 12:21:54 +0000
Subject: [issue41359] argparse mutually exclusive group does not exclude in
 some cases
In-Reply-To: <1595332007.75.0.283126282834.issue41359@roundup.psfhosted.org>
Message-ID: <1595334114.51.0.469972973885.issue41359@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41359>
_______________________________________

From report at bugs.python.org  Tue Jul 21 09:18:28 2020
From: report at bugs.python.org (Ilia Androshchuk)
Date: Tue, 21 Jul 2020 13:18:28 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595245426.33.0.812684814237.issue41345@roundup.psfhosted.org>
Message-ID: <1595337508.48.0.784807673442.issue41345@roundup.psfhosted.org>


Ilia Androshchuk <an7e at outlook.com> added the comment:

Hi Michal,
I found some information in the package documentation
Please check this page
https://requests.readthedocs.io/en/master/user/advanced/#keep-alive

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Tue Jul 21 09:58:01 2020
From: report at bugs.python.org (Alexey)
Date: Tue, 21 Jul 2020 13:58:01 +0000
Subject: [issue41360] method _tunnel does not allow for a standard proxy
 authentication solution
Message-ID: <1595339881.01.0.101864505877.issue41360@roundup.psfhosted.org>


New submission from Alexey <Namyotkin at mail.ru>:

The _tunnel method of the HTTPConnection class in the http.client module, if the CONNECT request is unsuccessful, closes the connection and raises an OSError without returning the response data. This behavior does not allow to implement the authentication procedure on the proxy server using methods similar to those used for authentication on servers (using hooks). And at the moment proxy authentication (Kerberos, Digest, NTLM - all other than Basic) is not supported by the urllib3 and accordingly requests, pip and many others. As a result, a large number of people cannot use Python to create scripts that involve working on the Internet (if they don't know workarounds). This problem has been mentioned many times here (Issue 7291, 24333, 24964). There are many Issues related to this task in requests, urllib3, pip and other. This problem is many years old (at least 5), but there is still no complete solution (as far as I can tell). There are several workarounds, but there is still no solution that could be used in urllib3, requests, pip and other (in many discussions of Issues _tunnel method is indicated as a reason preventing a proxy authentication solution from being implemented). Hopefully someone can finally solve this problem or explain why it can't be solved

----------
components: Library (Lib)
messages: 374067
nosy: Namyotkin
priority: normal
severity: normal
status: open
title: method _tunnel does not allow for a standard proxy authentication solution
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/issue41360>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:26:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jul 2020 15:26:01 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
Message-ID: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

There was no performance regressin with this change.

----------
components: Argument Clinic
messages: 374068
nosy: corona10, larry
priority: normal
severity: normal
status: open
title: Converting collections.deque methods to Argument Clinic
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:27:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jul 2020 15:27:40 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1595345260.93.0.26078445699.issue41361@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +20725
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21584

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:52:03 2020
From: report at bugs.python.org (Ilia Androshchuk)
Date: Tue, 21 Jul 2020 15:52:03 +0000
Subject: [issue41360] method _tunnel does not allow for a standard proxy
 authentication solution
In-Reply-To: <1595339881.01.0.101864505877.issue41360@roundup.psfhosted.org>
Message-ID: <1595346723.53.0.547379929389.issue41360@roundup.psfhosted.org>


Change by Ilia Androshchuk <an7e at outlook.com>:


----------
nosy: +an7e

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41360>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:53:11 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 21 Jul 2020 15:53:11 +0000
Subject: [issue41337] strangnedd with the parser
In-Reply-To: <1595142854.93.0.625652406.issue41337@roundup.psfhosted.org>
Message-ID: <1595346791.2.0.292409282592.issue41337@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

This appears to be a bug with the google colab site.

For whatever reason, if you try to evaluate a statement that is a line with  a leading comma (afaik, never valid python), then colab does something wierd by wrapping the arguments in quotes, and evaluating them ...

Here, `>>>` denotes running python in a colab cell:

>>> type(1)
int
>>> ,type(1)
str
>>> ,type(1,2,3)
str
>>> ,type(1, 2, 3)
---------------------------------------------------------------------------

TypeError                                 Traceback (most recent call last)

<ipython-input-38-a1b277d7db3e> in <module>()
----> 1 type("(1,", "2,", "3)")

TypeError: type.__new__() argument 2 must be tuple, not str

---

This is not reproducible in normal python, so seems extremely likely to be some (planned or unplanned) feature of google colab that's causing confusion here.

----------
nosy: +stestagg
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41337>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:57:54 2020
From: report at bugs.python.org (SD)
Date: Tue, 21 Jul 2020 15:57:54 +0000
Subject: [issue41299] Python3 threading.Event().wait time is twice as large as
 Python27
In-Reply-To: <1594764957.86.0.842448865524.issue41299@roundup.psfhosted.org>
Message-ID: <1595347074.14.0.120105609192.issue41299@roundup.psfhosted.org>


SD <scott-devine at hotmail.co.uk> added the comment:

So there is no advised way around this then. I am currently using time.sleep() to hit my 60hz.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41299>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:58:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2020 15:58:15 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595347095.19.0.22230223722.issue41327@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Windows 10 has a "Feedback Hub" to report problems and search for existing feedback that's similar.

This is the correct channel, but ultimately the "real" issue tracker is private, so all you'll ever get is "not finished yet" that suddenly becomes "finished" (and generally that's updated on release, not on commit, because we've found that users get confused when something is claimed to be fixed but they're still seeing the issue).

> IMO, the installer-redirector in this case should be a console application that prints a message to stdout to inform the user that it's opening the store to install Python.

This is exactly what it does. The fact that it is SUBSYSTEM:WINDOWS instead of CONSOLE is what I'm trying to get fixed. It's not complicated, it's just not something that anyone can force through besides the team that owns the code, and they own a lot of other things that need fixing as well (and the release schedule doesn't allow for "just one little fix"). Shipping an OS is *hard* ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Tue Jul 21 12:05:47 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 21 Jul 2020 16:05:47 +0000
Subject: [issue41337] strangnedd with the parser
In-Reply-To: <1595142854.93.0.625652406.issue41337@roundup.psfhosted.org>
Message-ID: <1595347547.19.0.00493696255803.issue41337@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this as not a python bug. If someone gets some evidence to the contrary, we can re-open it.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41337>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:08:13 2020
From: report at bugs.python.org (paul j3)
Date: Tue, 21 Jul 2020 17:08:13 +0000
Subject: [issue41359] argparse mutually exclusive group does not exclude in
 some cases
In-Reply-To: <1595332007.75.0.283126282834.issue41359@roundup.psfhosted.org>
Message-ID: <1595351293.99.0.784841709672.issue41359@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

This is the result of how default values are handled with '?' (and '*') nargs.

At the start of nested `take_action` function (which handles all actions) is this code:

            argument_values = self._get_values(action, argument_strings)

            # error if this argument is not allowed with other previously
            # seen arguments, assuming that actions that use the default
            # value don't really count as "present"
            if argument_values is not action.default:
                seen_non_default_actions.add(action)
                for conflict_action in action_conflicts.get(action, []):
                    if conflict_action in seen_non_default_actions:
                        msg = _('not allowed with argument %s')
                        action_name = _get_action_name(conflict_action)
                        raise ArgumentError(action, msg % action_name)

'get_values' gets the values for this action.  A bare '-b' will be given its 'default'. 

An optional positional is always 'seen', since an empty list satisfies its 'nargs'.  'get_values' assigns the default instead.  This code in take_action allows us to include such positionals in a mutually exclusive group.

This handing of the '?' optional is a byproduct of that code.  Normally we provide both a 'default' and a 'const' with such an argument, giving us a 3-way switch (default, const or user-value).  If either 'default' or 'const' is provided, your '-b' will behave as expected.

I have a feeling that trying to document this edge case will just make things more confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41359>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:09:20 2020
From: report at bugs.python.org (Constant Marks)
Date: Tue, 21 Jul 2020 17:09:20 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
Message-ID: <1595351360.26.0.0463175809492.issue41362@roundup.psfhosted.org>


New submission from Constant Marks <crmarksv at gmail.com>:

When calling `build.bat -d --regen' the graminit.c and graminit.h files are not generated with the following warnings:

Time Elapsed 00:02:49.06
  Killing any running python_d.exe instances...
  Getting build info from "C:\Program Files\Git\cmd\git.exe"
  Building heads/3.9-dirty:9e84a2c424 3.9
  pythoncore.vcxproj -> C:\Users\crm0376\source\repos\cpython\PCbuild\win32\python39_d.dll
  C:\Users\crm0376\source\repos\cpython\Parser\pgen\__main__.py:43: ResourceWarning: unclosed file <_io.TextIOWrapper name='C:\\Users\\crm0376\\source\\repos\\cpython\\PCbuild\\obj\\39win32_Debug\\regen\\graminit.h' mode='w' encoding='cp
  1252'>
    main()
  ResourceWarning: Enable tracemalloc to get the object allocation traceback
  C:\Users\crm0376\source\repos\cpython\Parser\pgen\__main__.py:43: ResourceWarning: unclosed file <_io.TextIOWrapper name='C:\\Users\\crm0376\\source\\repos\\cpython\\PCbuild\\obj\\39win32_Debug\\regen\\graminit.c' mode='w' encoding='cp
  1252'>
    main()
  ResourceWarning: Enable tracemalloc to get the object allocation traceback

----------
messages: 374074
nosy: constantmarks
priority: normal
severity: normal
status: open
title: Regenerating parser table fails (windows)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:21:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Jul 2020 17:21:41 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
In-Reply-To: <1595351360.26.0.0463175809492.issue41362@roundup.psfhosted.org>
Message-ID: <1595352101.73.0.948122695649.issue41362@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:23:05 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jul 2020 17:23:05 +0000
Subject: [issue41327] Windows Store "stub" Python executables give confusing
 behaviour
In-Reply-To: <1595011372.47.0.909809714315.issue41327@roundup.psfhosted.org>
Message-ID: <1595352185.48.0.0907908589672.issue41327@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> This is exactly what it does. The fact that it is SUBSYSTEM:WINDOWS

Sorry, I neglected to check:
 
    C:\>python3 script.py 2>&1 | more
    Python was not found but can be installed from the Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:38:02 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCf0LXRgNC10LLRkdGA0YLQutC40L0=?=)
Date: Tue, 21 Jul 2020 17:38:02 +0000
Subject: [issue41363] python 3.8.5 folder not visible in
 https://www.python.org/ftp/python/ listing
Message-ID: <1595353082.43.0.231243194909.issue41363@roundup.psfhosted.org>


New submission from ?????? ??????????? <irherder at gmail.com>:

Open https://www.python.org/ftp/python/ and observe that there is no 3.8.5 folder.
Open https://www.python.org/ftp/python/3.8.5/ and observe that all the expected files are present.

Conclusion: https://www.python.org/ftp/python/ index needs an update.

----------
messages: 374076
nosy: ?????? ???????????
priority: normal
severity: normal
status: open
title: python 3.8.5 folder not visible in https://www.python.org/ftp/python/ listing
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41363>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:40:38 2020
From: report at bugs.python.org (SilentGhost)
Date: Tue, 21 Jul 2020 17:40:38 +0000
Subject: [issue41363] python 3.8.5 folder not visible in
 https://www.python.org/ftp/python/ listing
In-Reply-To: <1595353082.43.0.231243194909.issue41363@roundup.psfhosted.org>
Message-ID: <1595353238.84.0.914326402199.issue41363@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41363>
_______________________________________

From report at bugs.python.org  Tue Jul 21 15:21:41 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Jul 2020 19:21:41 +0000
Subject: [issue41363] python 3.8.5 folder not visible in
 https://www.python.org/ftp/python/ listing
In-Reply-To: <1595353082.43.0.231243194909.issue41363@roundup.psfhosted.org>
Message-ID: <1595359301.5.0.105184727187.issue41363@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report. The python.org website sits behind a content delivery network service and sometimes it takes a little while for pages to be updated in the cache.  It should be there now.

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41363>
_______________________________________

From report at bugs.python.org  Tue Jul 21 15:24:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2020 19:24:26 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1595359466.12.0.649125888149.issue41361@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue20180. collections.deque was intentionally not converted to Argument Clinic, but some of methods were made using more efficient code for parsing arguments by inlining the code generated by Argument Clinic at that time.

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Jul 21 15:31:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2020 19:31:48 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595359908.49.0.541599191081.issue41288@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Tue Jul 21 16:41:32 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2020 20:41:32 +0000
Subject: [issue41364] Optimise uuid platform detection
Message-ID: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The uuid module calls platform.system() multiple times, even when the result is known from sys.platform. We can avoid some of these.

----------
assignee: steve.dower
components: Library (Lib)
messages: 374079
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Optimise uuid platform detection
type: performance
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Tue Jul 21 16:46:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2020 20:46:47 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595364407.53.0.689717306956.issue41364@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20726
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21586

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Tue Jul 21 18:23:30 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 21 Jul 2020 22:23:30 +0000
Subject: [issue35328] Set a environment variable for venv prompt
In-Reply-To: <1543335149.71.0.788709270274.issue35328@psf.upfronthosting.co.za>
Message-ID: <1595370210.82.0.689136081926.issue35328@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +20727
pull_request: https://github.com/python/cpython/pull/21587

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35328>
_______________________________________

From report at bugs.python.org  Tue Jul 21 18:30:24 2020
From: report at bugs.python.org (Lawrence D'Anna)
Date: Tue, 21 Jul 2020 22:30:24 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595370624.11.0.461345763556.issue41100@roundup.psfhosted.org>


Change by Lawrence D'Anna <lawrence_danna at apple.com>:


----------
pull_requests: +20728
pull_request: https://github.com/python/cpython/pull/21588

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Tue Jul 21 19:16:10 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2020 23:16:10 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595373370.71.0.90072852669.issue41364@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset bf2f76ec0976c09de79c8827764f30e3b6fba776 by Steve Dower in branch 'master':
bpo-41364: Reduce import overhead of uuid module (GH-21586)
https://github.com/python/cpython/commit/bf2f76ec0976c09de79c8827764f30e3b6fba776


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Tue Jul 21 19:16:24 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jul 2020 23:16:24 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595373384.29.0.167984322921.issue41364@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +20729
pull_request: https://github.com/python/cpython/pull/21589

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Tue Jul 21 20:09:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jul 2020 00:09:36 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595376576.24.0.959011652776.issue41364@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 00466db22168579509fe6aa6cb47cdd89dfb9141 by Miss Islington (bot) in branch '3.9':
bpo-41364: Reduce import overhead of uuid module (GH-21586)
https://github.com/python/cpython/commit/00466db22168579509fe6aa6cb47cdd89dfb9141


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Tue Jul 21 20:11:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Jul 2020 00:11:49 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595376709.08.0.623037385064.issue41364@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +20730
pull_request: https://github.com/python/cpython/pull/21591

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:16:02 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jul 2020 02:16:02 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1595384162.46.0.309859077352.issue41361@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> collections.deque was intentionally not converted to Argument Clinic,

Oh, I see ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Jul 21 23:28:48 2020
From: report at bugs.python.org (Chuck)
Date: Wed, 22 Jul 2020 03:28:48 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
Message-ID: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>


New submission from Chuck <chucktcl at hotmail.com>:

on Windows 10 64 after install of Python 3.8.5 and after install of decrypt_bitcoinj_seed.pyw <--- and after double click, I get "Python Launcher is sorry to say... No pyvenv.cfg file".  I have tried multiple reinstalls of Python to no avail. When a search is performed on the entire C:\ drive, no pyvenv.cfg file is present so c:\>python -m venv myenv c:\path\to\myenv does not create the pyvenv.cfg file.  The Python Script requires PIP (Google Protobuf and pylibscrypt) and I understand it's included in 3.8.5. Please provide step by step instructions for how to either create or download the pyvenv.cfg file and the exact Python path to folder name it needs to go so I can overcome this error. Or if someone has a different solution, that's fine too... I just need the decrypt_bitcoinj_seed.pyw to work.

----------
components: Windows
messages: 374083
nosy: Packhash, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python Launcher is sorry to say... No pyvenv.cfg file
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Tue Jul 21 23:49:41 2020
From: report at bugs.python.org (Henry Schreiner)
Date: Wed, 22 Jul 2020 03:49:41 +0000
Subject: [issue41366] sign-conversion warning in 3.9 beta
Message-ID: <1595389781.15.0.650471141646.issue41366@roundup.psfhosted.org>


New submission from Henry Schreiner <henryschreineriii at gmail.com>:

The macro Py_UNICODE_COPY was replaced by a function in CPython 3.9, and that function cannot compile with full warnings enabled + warnings as errors under Clang. The problematic line:

Py_DEPRECATED(3.3) static inline void
Py_UNICODE_COPY(Py_UNICODE *target, const Py_UNICODE *source, Py_ssize_t length) {
    memcpy(target, source, length * sizeof(Py_UNICODE));
}

has an implicit conversion of Py_ssize_t into size_t, which creates:

/Users/runner/hostedtoolcache/Python/3.9.0-beta.5/x64/include/python3.9/cpython/unicodeobject.h:55:: implicit conversion changes signedness: 'Py_ssize_t' (aka 'long') to 'unsigned long' [-Werror,-Wsign-conversion]

error: implicit conversion changes signedness: 'Py_ssize_t' (aka 'long') to 'unsigned long' [-Werror,-Wsign-conversion]
    memcpy(target, source, length * sizeof(Py_UNICODE));    memcpy(target, source, length * sizeof(Py_UNICODE));

An explicit cast to size_t (is there a Py_size_t?) should be made.

----------
components: C API
messages: 374084
nosy: Henry Schreiner
priority: normal
severity: normal
status: open
title: sign-conversion warning in 3.9 beta
type: compile error
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41366>
_______________________________________

From report at bugs.python.org  Tue Jul 21 23:58:58 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2020 03:58:58 +0000
Subject: [issue41366] sign-conversion warning in 3.9 beta
In-Reply-To: <1595389781.15.0.650471141646.issue41366@roundup.psfhosted.org>
Message-ID: <1595390338.2.0.0185845370626.issue41366@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20731
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21592

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41366>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:26:50 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jul 2020 05:26:50 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1595395609.99.0.774613112223.issue41361@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Now Argument Clinic generates more efficient (but more cumbersome) code, so there may be new reasons of using it. Please test the performance of the deque constructor (deque(), deque(()), deque((), 10), deque((), maxlen=10)), methods index() and rotate(), builtins iter() and reversed(). It is hard to test insert() because it mutates the deque and I do not expect anything beside noise for other methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:32:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jul 2020 05:32:06 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595395926.34.0.0447433803541.issue41288@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This fix touched the unpickling code, and the test crashed during pickling, so it is not directly related. But it may be some compiler glitch, when changing one part of code affects compilation of other parts of code. The next run on the buildbot was passed, and there were failures in the past (but logs were not saved), so it may be just unstable test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:33:12 2020
From: report at bugs.python.org (Daniel Smejkal)
Date: Wed, 22 Jul 2020 05:33:12 +0000
Subject: [issue37709] CSVReader ignores dialect.lineterminator
In-Reply-To: <1564428728.47.0.33259508348.issue37709@roundup.psfhosted.org>
Message-ID: <1595395992.93.0.245635173614.issue37709@roundup.psfhosted.org>


Change by Daniel Smejkal <dandasssan147 at gmail.com>:


----------
assignee:  -> docs at python
components: +2to3 (2.x to 3.x conversion tool), Documentation, email
nosy: +barry, docs at python, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37709>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:54:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2020 06:54:37 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1595400877.28.0.284486585731.issue41361@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Wed Jul 22 03:19:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2020 07:19:48 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1595402388.78.0.189805692749.issue41361@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think we should skip applying the clinic to the code. It jumbles the code quite a bit but doesn't give any real benefit.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Wed Jul 22 03:39:23 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 22 Jul 2020 07:39:23 +0000
Subject: [issue41356] Convert bool.__new__ to argument clinic
In-Reply-To: <1595325636.21.0.753393963516.issue41356@roundup.psfhosted.org>
Message-ID: <1595403563.8.0.0718873741087.issue41356@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

More microbenchmarks:

pyperf timeit "bool()"
    Before: 63.1 ns +- 0.7 ns
    After:  51.7 ns +- 1.2 ns

pyperf timeit "bool(0)"
    Before: 77.4 ns +- 1.9 ns
    After:  67.2 ns +- 1.3 ns

pyperf timeit "bool(17)"
    Before: 77.3 ns +- 2.3 ns
    After:  67.1 ns +- 1.0 ns

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41356>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:05:08 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Jul 2020 08:05:08 +0000
Subject: [issue41358] Unable to uninstall Python launcher using command line
In-Reply-To: <1595327997.84.0.414162156618.issue41358@roundup.psfhosted.org>
Message-ID: <1595405108.8.0.616599556816.issue41358@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41358>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:42:59 2020
From: report at bugs.python.org (Joan Prat Rigol)
Date: Wed, 22 Jul 2020 08:42:59 +0000
Subject: [issue41367] Popen Timeout raised on 3.6 but not on 3.8
Message-ID: <1595407379.06.0.696065311763.issue41367@roundup.psfhosted.org>


New submission from Joan Prat Rigol <pratjunior at gmail.com>:

If I run this code in Python 3.8 I get the result as expected:

Python 3.8.2 (default, Apr 27 2020, 15:53:34) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> process = subprocess.Popen("sudo -Si ls -l /home", shell=True, stdin=-1, stdout=-1, stderr=-1)
>>> out, err = process.communicate(input="Pr4tR1g01J04n\n".encode(), timeout=2)
>>> print(out)
b'total 4\ndrwxr-xr-x 43 joan joan 4096 Jul 22 09:46 joan\n'
>>> 
But If I run the code in Python 3.6 I am getting a timeout:

Python 3.6.9 (default, Apr 18 2020, 01:56:04) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> process = subprocess.Popen("sudo -Si ls -l /home", shell=True, stdin=-1, stdout=-1, stderr=-1)
>>> out, err = process.communicate(input="Pr4tR1g01J04n\n".encode(), timeout=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/subprocess.py", line 863, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/usr/lib/python3.6/subprocess.py", line 1535, in _communicate
    self._check_timeout(endtime, orig_timeout)
  File "/usr/lib/python3.6/subprocess.py", line 891, in _check_timeout
    raise TimeoutExpired(self.args, orig_timeout)
subprocess.TimeoutExpired: Command 'sudo -Si ls -l /home' timed out after 2 seconds
>>> 
Is this a bug?

----------
messages: 374089
nosy: Joan Prat Rigol
priority: normal
severity: normal
status: open
title: Popen Timeout raised on 3.6 but not on 3.8
versions: Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41367>
_______________________________________

From report at bugs.python.org  Wed Jul 22 06:17:09 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 22 Jul 2020 10:17:09 +0000
Subject: [issue40979] typing module docs: keep text, add subsections
In-Reply-To: <1592164571.1.0.235029301981.issue40979@roundup.psfhosted.org>
Message-ID: <1595413029.62.0.237084689413.issue40979@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

FWIW I like Guido's suggestion in the PR, I would rather use "importance order" than alphabetical order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40979>
_______________________________________

From report at bugs.python.org  Wed Jul 22 07:26:41 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Jul 2020 11:26:41 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595417201.95.0.340186335606.issue41364@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a18f22ab11a7bfb5ff3e74c737ca9e1bebe4abf9 by Steve Dower in branch '3.8':
bpo-41364: Reduce import overhead of uuid module (GH-21586)
https://github.com/python/cpython/commit/a18f22ab11a7bfb5ff3e74c737ca9e1bebe4abf9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Wed Jul 22 07:27:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Jul 2020 11:27:00 +0000
Subject: [issue41364] Optimise uuid platform detection
In-Reply-To: <1595364092.15.0.501059723351.issue41364@roundup.psfhosted.org>
Message-ID: <1595417220.86.0.459678916395.issue41364@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41364>
_______________________________________

From report at bugs.python.org  Wed Jul 22 07:37:22 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Jul 2020 11:37:22 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
In-Reply-To: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>
Message-ID: <1595417842.34.0.822366124517.issue41365@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It seems like you're trying to launch the python.exe that is created for a virtual environment rather than the actual one. This probably means that at some point you created a virtual environment and updated your file association to launch it.

The best thing to do is to right-click your .pyw file, choose "Open With", "Choose another app", enable "Always open ..." and choose "Python" from its list (the icon should have a space shuttle being launched). That will switch you back to the original file association.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Wed Jul 22 11:33:33 2020
From: report at bugs.python.org (Max)
Date: Wed, 22 Jul 2020 15:33:33 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595432013.86.0.0692696706479.issue39603@roundup.psfhosted.org>


Max <maxpl0it at protonmail.com> added the comment:

I've just noticed an issue with the current version of the patch. It should also include 0x20 (space) since that can also be used to manipulate the request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Wed Jul 22 11:38:45 2020
From: report at bugs.python.org (Chuck)
Date: Wed, 22 Jul 2020 15:38:45 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
In-Reply-To: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>
Message-ID: <1595432325.07.0.116649559836.issue41365@roundup.psfhosted.org>


Chuck <chucktcl at hotmail.com> added the comment:

Mr. Dower, I apologize for not being more specific... since this is Windows based and not console driven, the file used for execution should be pythonw.exe according to the instructions at https://github.com/gurnec/decrypt_bitcoinj_seed so I right clicked on decrypt_bitcoinj_seed.pyw and went to properties and changed it's association to pythonw.exe so it would run in a non-console manner.  After doing this however, it still didn't work with the error "No pyvenv.cfg file".  Would I still follow your instructions, choosing Python instead of pythonw.exe?  Do you happen to know why the pyvenv.cfg never got created in the first place?  After all, when I do a search it's no where to be found on my C: drive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Wed Jul 22 12:01:52 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 22 Jul 2020 16:01:52 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1595433712.21.0.210294852581.issue39603@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> It should also include 0x20 (space) since that can also be used to manipulate the request.

Can you indicate how to use a space in the HTTP verb as part of an attack?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Wed Jul 22 12:03:56 2020
From: report at bugs.python.org (Howard A. Landman)
Date: Wed, 22 Jul 2020 16:03:56 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595433836.78.0.397155684428.issue41335@roundup.psfhosted.org>


Howard A. Landman <howard at riverrock.org> added the comment:

This is not a memory leak problem. "Top" reports VIRT 21768 RES 13516 for the whole run, and Python internal resource reporting says 13564 kb for the whole run. So that's less than 1 kb leaked in 118.6M measurement cycles; most likely zero.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Wed Jul 22 12:16:30 2020
From: report at bugs.python.org (Wicher Minnaard)
Date: Wed, 22 Jul 2020 16:16:30 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1595434590.2.0.527907746425.issue37095@roundup.psfhosted.org>


Change by Wicher Minnaard <wicher at gavagai.eu>:


----------
nosy: +wicher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Wed Jul 22 13:02:04 2020
From: report at bugs.python.org (Chuck)
Date: Wed, 22 Jul 2020 17:02:04 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
In-Reply-To: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>
Message-ID: <1595437324.44.0.874051096674.issue41365@roundup.psfhosted.org>


Chuck <chucktcl at hotmail.com> added the comment:

Does anyone know why when Python Launcher is executed by double clicking on the Python script called ecrypt_bitcoinj_seed.pyw a small window pops of stating... "Python Launcher is sorry to say... No pyvenv.cfg file" as in the image? Why wouldn't the pyvenv.cfg file NOT get created like it's supposed to.  After doing a search for it on C: drive it is not found.  If anyone has a copy of the file, would you please provide it and also tell me the folder to place it in? Thank you

----------
Added file: https://bugs.python.org/file49330/screenshot.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Wed Jul 22 13:10:15 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 22 Jul 2020 17:10:15 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595437815.67.0.468262899217.issue41100@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Wed Jul 22 14:06:10 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Jul 2020 18:06:10 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
In-Reply-To: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>
Message-ID: <1595441170.13.0.0271253676058.issue41365@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> "Python Launcher is sorry to say... No pyvenv.cfg file" 

As already mentioned, that it fails with this error means you're running a virtual-environment launcher instead of a base Python executable. That it displays a message box means you ran a GUI pythonw.exe virtual-environment launcher. pyvenv.cfg is a configuration file that the virtual-environment launcher looks for beside the executable, or one directory up. It tells the launcher where to find the base python[w].exe executable.

As already suggested, you should associate .py[w] scripts with the "Python" app that depicts a rocket/shuttle being launched on its icon. This will associate .py[w] scripts with the py[w].exe launcher, and it also associates them with a shell drop handler that allows files to be dragged and dropped on a script icon in Explorer.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Wed Jul 22 14:13:57 2020
From: report at bugs.python.org (William Pickard)
Date: Wed, 22 Jul 2020 18:13:57 +0000
Subject: [issue41368] Allow compiling Python with llvm-clang on Windows.
Message-ID: <1595441637.36.0.539445300031.issue41368@roundup.psfhosted.org>


New submission from William Pickard <lollol222gg at gmail.com>:

Since Visual Studio 2017, Microsoft has an optional C++ Desktop Development option for compiling C/C++ code with LLVM's Clang compiler.

It's called: Clang with Microsoft CodeGen.
While the code is parsed with LLVM's Clang parser, the code is generated with a MSVC compatible code generator (hence the "with Microsoft CodeGen" name suffix)

Currently, Python 3.10 is uncompilable with Clang, but I would appreciate it if it can be supported.

I have attached a build log from MSBuild, below is the commandline I used to run the build.

Start-Process -FilePath $(Join-Path $PCBUILD -ChildPath 'build.bat' -Resolve) -WorkingDirectory $PCBuild -NoNewWindow -RedirectStandardOut $BUILD_LOG -RedirectStandardError $BUILDERROR_LOG -ArgumentList '-m', '-v', '-c', 'Debug', '-p', 'x64', '-t', 'Build', '"/p:PlatformToolset=ClangCL"'
PS L:\GIT\cpython> Start-Process -FilePath $(Join-Path $PCBUILD -ChildPath 'build.bat' -Resolve) -WorkingDirectory $PCBuild -NoNewWindow -RedirectStandardOut $BUILD_LOG -RedirectStandardError $BUILDERROR_LOG -ArgumentList '-m', '-v', '-c', 'Debug', '-p', 'x64', '-t', 'Build', '"/p:PlatformToolset=ClangCL"'

----------
components: Cross-Build, Windows
files: build.log
messages: 374099
nosy: Alex.Willmer, William Pickard, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Allow compiling Python with llvm-clang on Windows.
type: compile error
versions: Python 3.10
Added file: https://bugs.python.org/file49331/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41368>
_______________________________________

From report at bugs.python.org  Wed Jul 22 14:46:03 2020
From: report at bugs.python.org (William Pickard)
Date: Wed, 22 Jul 2020 18:46:03 +0000
Subject: [issue41368] Allow compiling Python with llvm-clang on Windows.
In-Reply-To: <1595441637.36.0.539445300031.issue41368@roundup.psfhosted.org>
Message-ID: <1595443563.86.0.537280294801.issue41368@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

Note: Apparently Google-OpenID login button created a seperate account... instead of finding this one.

----------
nosy: +WildCard65 -William Pickard

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41368>
_______________________________________

From report at bugs.python.org  Wed Jul 22 15:27:21 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Jul 2020 19:27:21 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
Message-ID: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

This issue tracks the update of the included libmpdec to version 2.5.1.

The version includes features required for #41324.

----------
assignee: skrah
components: Extension Modules
messages: 374101
nosy: skrah
priority: normal
severity: normal
status: open
title: Update to libmpdec-2.5.1
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Wed Jul 22 15:31:22 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Jul 2020 19:31:22 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1595446282.16.0.515536154911.issue41369@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
keywords: +patch
pull_requests: +20732
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21593

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Wed Jul 22 15:47:35 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 22 Jul 2020 19:47:35 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595447255.94.0.0806338979986.issue41341@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 653f420b53a3aa87316cef59de8d3f5d9e11deb4 by wyfo in branch 'master':
bpo-41341: Recursive evaluation of ForwardRef in get_type_hints (#21553)
https://github.com/python/cpython/commit/653f420b53a3aa87316cef59de8d3f5d9e11deb4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Wed Jul 22 15:54:49 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Jul 2020 19:54:49 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1595447689.59.0.250474527791.issue41369@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 9b9f1582753979f38d2fd927cddf0621a65e9ed6 by Stefan Krah in branch 'master':
bpo-41369 Update to libmpdec-2.5.1: new features (GH-21593)
https://github.com/python/cpython/commit/9b9f1582753979f38d2fd927cddf0621a65e9ed6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:02:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 22 Jul 2020 20:02:01 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595448121.84.0.0797128594373.issue41341@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

?ukasz, can I please have a decision on whether to backport this bugfix to 3.9?

See my comment about that:
https://github.com/python/cpython/pull/21553#pullrequestreview-452895735

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:16:14 2020
From: report at bugs.python.org (Joseph Perez)
Date: Wed, 22 Jul 2020 20:16:14 +0000
Subject: [issue41370] PEP 585 and ForwardRef
Message-ID: <1595448974.26.0.905372860878.issue41370@roundup.psfhosted.org>


New submission from Joseph Perez <joperez at hotmail.fr>:

PEP 585 current implementation (3.10.0a0) differs from current Generic implementation about ForwardRef, as illustrated bellow:
```python
from dataclasses import dataclass, field
from typing import get_type_hints, List, ForwardRef

@dataclass
class Node:
    children: list["Node"] = field(default_factory=list)
    children2: List["Node"] = field(default_factory=list)

assert get_type_hints(Node) == {"children": list["Node"], "children2": List[Node]}
assert List["Node"].__args__ == (ForwardRef("Node"),)
assert list["Node"].__args__ == ("Node",) # No ForwardRef here, so no evaluation by get_type_hints
```
There is indeed no kind of ForwardRef for `list` arguments. As shown in the example, this affects the result of get_type_hints for recursive types handling.

He could be "fixed" in 2 lines in `typing._eval_type` with something like this :
```python
def _eval_type(t, globalns, localns, recursive_guard=frozenset()):
    if isinstance(t, str):
        t = ForwardRef(t)
    if isinstance(t, ForwardRef):
       ...
```
but it's kind of hacky/dirty.

It's true that this issue will not concern legacy code, 3.9 still being not released. So developers of libraries using get_type_hints could add in their documentation that `from __future__ import annotations` is mandatory for recursive types with PEP 585 (I think I will do it).

By the way, Guido has quickly given his opinion about it in PR 21553: "We probably will not ever support this: importing ForwardRef from the built-in generic alias code would be problematic, and once from __future__ import annotations is always on there's no need to quote the argument anyway." (So feel free to close this issue)

----------
messages: 374105
nosy: BTaskaya, eric.smith, gvanrossum, joperez, levkivskyi, lukasz.langa, vstinner
priority: normal
severity: normal
status: open
title: PEP 585 and ForwardRef
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41370>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:17:30 2020
From: report at bugs.python.org (doodspav)
Date: Wed, 22 Jul 2020 20:17:30 +0000
Subject: [issue41371] test_zoneinfo fails
Message-ID: <1595449050.37.0.742582022147.issue41371@roundup.psfhosted.org>


New submission from doodspav <doodspav at gmail.com>:

Issue:
======
`_lzma` is not built because the required libraries are not available on my machine. `test_zoneinfo` assumes it is always available, leading it to crash on my machine.

How I build and ran the tests:
==============================
git clone https://github.com/python/cpython.git  (bpo-41364)
cd cpython
mkdir build && cd build
../configure
make -j8
make test > test_output.txt

Test traceback:
===============
  File "/home/doodspav/Jetbrains/CLionProjects/cpython/Lib/test/libregrtest/runtest.py", line 272, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "/home/doodspav/Jetbrains/CLionProjects/cpython/Lib/test/libregrtest/runtest.py", line 223, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "/home/doodspav/Jetbrains/CLionProjects/cpython/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/home/doodspav/Jetbrains/CLionProjects/cpython/Lib/test/test_zoneinfo/__init__.py", line 1, in <module>
    from .test_zoneinfo import *
  File "/home/doodspav/Jetbrains/CLionProjects/cpython/Lib/test/test_zoneinfo/test_zoneinfo.py", line 9, in <module>
    import lzma
  File "/home/doodspav/Jetbrains/CLionProjects/cpython/Lib/lzma.py", line 27, in <module>
    from _lzma import *
ModuleNotFoundError: No module named '_lzma'

----------
components: Tests
files: test_output.txt
messages: 374106
nosy: doodspav
priority: normal
severity: normal
status: open
title: test_zoneinfo fails
type: crash
versions: Python 3.10
Added file: https://bugs.python.org/file49332/test_output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41371>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:19:34 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 22 Jul 2020 20:19:34 +0000
Subject: [issue41370] PEP 585 and ForwardRef
In-Reply-To: <1595448974.26.0.905372860878.issue41370@roundup.psfhosted.org>
Message-ID: <1595449174.21.0.563315086625.issue41370@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I think mentioning this in the docs is the best we can do in 3.9, and for 3.10 the point will be moot. The next release is release candidate 1, so we're well past the point where we can implement new functionality.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41370>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:21:10 2020
From: report at bugs.python.org (Prakhar Goel)
Date: Wed, 22 Jul 2020 20:21:10 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1595449270.06.0.235058431338.issue33129@roundup.psfhosted.org>


Prakhar Goel <newt0311 at gmail.com> added the comment:

Hi,

As another piece of evidence: I run into this problem _all the time_. Whenever I need a field in the parent with a default, I either need to add bogus default values for every field in every subclass or just skip the default in the parent.

I'd like to suggest a middle ground:
1. A field level keyword_only option which forces just that field to be a kw-only field (for every subclass as well).
2. A class level keyword_only option that does:
2a. False (default) means current behavior where classes are not keyword only (but may be forced to be by the field specific arg).
2b. True means all the fields in this class (but not the subclasses!) Would be marked as keyword only. This does affect the order of arguments in the init method but that seems acceptable given that keyword only parameters are conceptually order independent.
2c. None implies that precisely the fields with a default (or default_factory) should be keyword only fields.

Thoughts?

----------
nosy: +Prakhar Goel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:24:41 2020
From: report at bugs.python.org (pmp-p)
Date: Wed, 22 Jul 2020 20:24:41 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1595449481.75.0.373539302276.issue33129@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:38:41 2020
From: report at bugs.python.org (Joseph Perez)
Date: Wed, 22 Jul 2020 20:38:41 +0000
Subject: [issue41370] PEP 585 and ForwardRef
In-Reply-To: <1595448974.26.0.905372860878.issue41370@roundup.psfhosted.org>
Message-ID: <1595450321.15.0.899188763947.issue41370@roundup.psfhosted.org>


Joseph Perez <joperez at hotmail.fr> added the comment:

However, PEP 563 will not solve the recursive type alias issue like `A = list["A"]` but this is a minor concern.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41370>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:06:19 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2020 21:06:19 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595451979.75.0.397125562617.issue41317@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Alex, do you want to submit a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:10:11 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 22 Jul 2020 21:10:11 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595452211.33.0.788991008702.issue41317@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Sure, it should be a rather straightforward fix. I have to check if the tests for the related methods test for proper cancellation semantics. It should be even faster if they do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:12:12 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Wed, 22 Jul 2020 21:12:12 +0000
Subject: [issue41357] pathlib.Path.resolve incorrect os.path equivalent
In-Reply-To: <1595327489.48.0.566751491612.issue41357@roundup.psfhosted.org>
Message-ID: <1595452332.44.0.109039707083.issue41357@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
nosy: +Jeffrey.Kintscher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41357>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:21:15 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 22 Jul 2020 21:21:15 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595452875.21.0.0477589771183.issue41317@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Looks like they do ? fantastic!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:34:35 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 22 Jul 2020 21:34:35 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595453675.71.0.719864462314.issue4630@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +20733
pull_request: https://github.com/python/cpython/pull/21594

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:50:02 2020
From: report at bugs.python.org (doodspav)
Date: Wed, 22 Jul 2020 21:50:02 +0000
Subject: [issue41371] test_zoneinfo fails
In-Reply-To: <1595449050.37.0.742582022147.issue41371@roundup.psfhosted.org>
Message-ID: <1595454602.28.0.074447382744.issue41371@roundup.psfhosted.org>


doodspav <doodspav at gmail.com> added the comment:

Note:
=====
I marked the type as `crash` because during the test run, the first attempt at `test_zoneinfo` failed with a segfault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41371>
_______________________________________

From report at bugs.python.org  Wed Jul 22 18:22:24 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 22 Jul 2020 22:22:24 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595456544.14.0.334301480708.issue41317@roundup.psfhosted.org>


Change by Alex Gr?nholm <alex.gronholm at nextday.fi>:


----------
keywords: +patch
pull_requests: +20734
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21595

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Wed Jul 22 18:39:11 2020
From: report at bugs.python.org (Bar Harel)
Date: Wed, 22 Jul 2020 22:39:11 +0000
Subject: [issue41372] Log exception never retrieved in concurrent.futures
Message-ID: <1595457551.15.0.0734023234178.issue41372@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Asyncio has an amazing mechanism showing "Task exception was never retrieved" or "Future exception was never retrieved" if the task threw an exception, and no one checked its `.result()` or `.exception()`.

It does so by setting a private variable named `__log_traceback` to False upon retrieval, and logging at `__del__` if the exception wasn't retrieved.

I believe it's a very important mechanism missing from concurrent.futures. It's very easy to implement.

I wanted to see if there's any disagreement before I implement it though. It's small enough to not need python-ideas yet important enough for inclusion I believe.

Regarding potential issues - I can only see issues with unlikely deadlocks at `__del__` (think of a handler taking a lock and this occurs during the handling of another log record). Asyncio however already took that bet, and although it's less planned for multi-threading, it's still a bet that was totally worth it.

----------
components: Library (Lib)
messages: 374114
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Log exception never retrieved in concurrent.futures
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41372>
_______________________________________

From report at bugs.python.org  Wed Jul 22 18:39:39 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Wed, 22 Jul 2020 22:39:39 +0000
Subject: [issue41357] pathlib.Path.resolve incorrect os.path equivalent
In-Reply-To: <1595327489.48.0.566751491612.issue41357@roundup.psfhosted.org>
Message-ID: <1595457579.07.0.596131098996.issue41357@roundup.psfhosted.org>


Jeffrey Kintscher <websurfer at surf2c.net> added the comment:

I uploaded a script illustrating the differences between how Path.resolve(), os.path.abspath(), and os.path.realpath() handle symlinks.  As noted by Jendrik, Path.resolve() and os.path.realpath() both resolve symlinks, while os.path.abspath() does not.  The documentation needs to be updated.  I will generate a pull request.

Example run on the master branch:

python version:
3.9.0a0 (heads/master-dirty:f69d5c6198, Jul 16 2019, 12:38:41) 
[Clang 10.0.1 (clang-1001.0.46.4)]
----
tdir1: /var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo1
creating tdir1
tdir2: /var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo2
creating tdir2 as symlink to tdir1
Path(tdir1).resolve(): /private/var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo1
Path(tdir2).resolve(): /private/var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo1
os.path.abspath(tdir1): /var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo1
os.path.abspath(tdir2): /var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo2
os.path.realpath(tdir1): /private/var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo1
os.path.realpath(tdir2): /private/var/folders/w7/mxt827716xs7_3wbk3mqwd3h0000gn/T/tmpyj7juuca/foo1

----------
Added file: https://bugs.python.org/file49333/bpo-41537-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41357>
_______________________________________

From report at bugs.python.org  Wed Jul 22 18:42:11 2020
From: report at bugs.python.org (Bar Harel)
Date: Wed, 22 Jul 2020 22:42:11 +0000
Subject: [issue41372] Log exception never retrieved in concurrent.futures
In-Reply-To: <1595457551.15.0.0734023234178.issue41372@roundup.psfhosted.org>
Message-ID: <1595457731.34.0.385869006619.issue41372@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41372>
_______________________________________

From report at bugs.python.org  Wed Jul 22 20:18:26 2020
From: report at bugs.python.org (Ma Lin)
Date: Thu, 23 Jul 2020 00:18:26 +0000
Subject: [issue41265] lzma/bz2 module: inefficient buffer growth algorithm
In-Reply-To: <1594370733.96.0.701626485898.issue41265@roundup.psfhosted.org>
Message-ID: <1595463506.93.0.818987940091.issue41265@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

I'm working on a patch.
lzma decompressing speed increases:

baseline: 0.275722 sec
patched:  0.140405 sec
(Uncompressed data size 52.57 MB)


The new algorithm looks like this:

    #define INITIAL_BUFFER_SIZE (16*1024)

    static inline Py_ssize_t
    get_newsize(Py_ssize_t size)
    {
        const Py_ssize_t MB = 1024*1024;
        const Py_ssize_t GB = 1024*1024*1024;

        if (size <= 1*MB) {
            return size << 2;           // x4
        } else if (size <= 128*MB) {
            return size << 1;           // x2
        } else if (size <= 1*GB) {
            return size + (size >> 1);  // x1.5
        } else if (size <= 2*GB) {
            return size + (size >> 2);  // x1.25
        } else {
            return size + (size >> 3);  // x1.125
        }
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41265>
_______________________________________

From report at bugs.python.org  Wed Jul 22 20:56:59 2020
From: report at bugs.python.org (Howard A. Landman)
Date: Thu, 23 Jul 2020 00:56:59 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1595465819.28.0.300625846234.issue12423@roundup.psfhosted.org>


Howard A. Landman <howard at riverrock.org> added the comment:

I don't think changing the documentation makes this not be a bug. My situation: I have a Python 3.7.3 program that reliably dies (after about 13 hours, having called its measure() method between 118.6M and 118.7M times) with free(): invalid pointer, which calls abort(). I believe that this is a bug in Python; and it's NOT a memory leak, since the size of the program doesn't change at all over time and is under 14 MB (real). I would like to debug it. This basically says "you're screwed". I can't catch the abort, and I can't use python3-dbg because it won't bind with the RPi.GPIO or spidev libraries. So all I can get from a core dump is that free() is being called by list_ass_item() at ../Objects/listobject.c line 739. Assuming that I'm right and that this is a bug in Python, how do you expect anyone to ever debug it? At a bare minimum, there needs to be an easy way to get a full stack trace through both Python and C.

----------
nosy: +Howard_Landman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Wed Jul 22 21:08:12 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Thu, 23 Jul 2020 01:08:12 +0000
Subject: [issue41357] pathlib.Path.resolve incorrect os.path equivalent
In-Reply-To: <1595327489.48.0.566751491612.issue41357@roundup.psfhosted.org>
Message-ID: <1595466492.0.0.872558148423.issue41357@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
keywords: +patch
pull_requests: +20735
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41357>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:05:37 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 23 Jul 2020 03:05:37 +0000
Subject: [issue41371] test_zoneinfo fails
In-Reply-To: <1595449050.37.0.742582022147.issue41371@roundup.psfhosted.org>
Message-ID: <1595473537.52.0.158358452938.issue41371@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41371>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:13:44 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 03:13:44 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1595474024.74.0.104324503794.issue41182@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bcd47837a9bf4806e559b40df73869493efcce27 by Abhijeet Kasurde in branch 'master':
bpo-41182 selector: use DefaultSelector based upon implementation (GH-21257)
https://github.com/python/cpython/commit/bcd47837a9bf4806e559b40df73869493efcce27


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:47:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 03:47:16 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
Message-ID: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

#41300 fixed one bug in the patch for #41158.  A user reported another on on idle-dev list.  Create a file in Windows Explorer.  Leave as .txt or rename to .py.  Right click and Edit with IDLE 3.8 (.4/.5 or 3.9.0b4 or 5).  Edit works, Save (or Run) does not.  Open the same file from Command Prompt, change it, and trying to save produces

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python38\lib\tkinter\__init__.py", line 1883, in __call__
    return self.func(*args)
  File "C:\Programs\Python38\lib\idlelib\multicall.py", line 176, in handler
    r = l[i](event)
  File "C:\Programs\Python38\lib\idlelib\iomenu.py", line 200, in save
    if self.writefile(self.filename):
  File "C:\Programs\Python38\lib\idlelib\iomenu.py", line 232, in writefile
    text = self.fixnewlines()
  File "C:\Programs\Python38\lib\idlelib\iomenu.py", line 252, in fixnewlines
    text = text.replace("\n", self.eol_convention)
TypeError: replace() argument 2 must be str, not None

The replacement line is guarded with
        if self.eol_convention != "\n":
Either the condition should be include 'and self.eol_convention is not None' or the setting of the attribute should be changed.  I will look into how it was set before the #41158 patch.

----------
messages: 374119
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: edit/save files created by Windows Explorer
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:28:52 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Jul 2020 04:28:52 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595478532.24.0.872076191404.issue41045@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I've reviewed your first PR (#21509).

Regarding your second one, I think there's a misunderstanding. With "pydoc" I didn't mean "the Python docs". IMO the documentation of f-strings in the language reference is sufficient, there's no need for another section about it in the library reference.

What I meant was that the pydoc *module* doesn't have any text about f-strings. The help() builtin calls pydoc.help(), and there are some *special* topics that you can invoke whose source text is generated
by running `make pydoc-topics` in the Doc directory and copying the output into Lib/pydoc_data/. There is a list of topics included in Doc/tools/extensions/pyspecific.py (pydoc_topic_labels) and something has to be added there. But beware! This code is tricky. You also need to add an entry to pydoc.py itself, to the dict named 'topics' around line 1891. I think you can just add an entry FSTRINGS to the latter and make it point to the section labeled f-strings in the language reference (which you are updating in PR 21509).

Let me know if you need more help (I had a fun hour figuring out how all this works :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:00:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2020 06:00:15 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595484015.89.0.143089901339.issue41373@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I missed that the file's attribute newlines can be None if no line separators were read. It can also be a tuple if mixed newlines are used. I think that eol_convention should be set to the default value os.linesep in these cases.

I am currently not able to test this since IDLE does not work on my computer after upgrading to Ubuntu 20.04.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:02:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2020 06:02:37 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595484157.32.0.510555592041.issue41373@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20736
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21597

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:06:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 06:06:33 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595484393.3.0.0887982973229.issue4630@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 592527f3ee59616eca2bd1da771f7c14cee808d5 by Zackery Spytz in branch 'master':
bpo-4630: Fix errors in Lib/idlelib/NEWS.txt (GH-21594)
https://github.com/python/cpython/commit/592527f3ee59616eca2bd1da771f7c14cee808d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:06:51 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 06:06:51 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595484411.73.0.951770520101.issue4630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20737
pull_request: https://github.com/python/cpython/pull/21598

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:14:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2020 06:14:24 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1595484864.45.0.682533849075.issue37095@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The tarfile module supports arbitrary compressions by using the stream mode. You only need to use a third-party library which provides zstd support.

Recent versions of the tar utility has options to explicit support of new compressions: --lzip, --lzma, --lzop, --zstd, so corresponding modes can be added to the tarfile module. But it needs to include the support of these compressions in the stdlib. It should be discussed on the Python-ideas mailing list.

https://mail.python.org/mailman3/lists/python-ideas.python.org/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:15:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 06:15:06 +0000
Subject: [issue41300] IDLE: add missing import io in iomenu.py
In-Reply-To: <1594776211.42.0.863093629881.issue41300@roundup.psfhosted.org>
Message-ID: <1595484906.0.0.341445298149.issue41300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#41373 is about another issue with the new iomenu code.  I will close this and add tests there.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41300>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:18:34 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Thu, 23 Jul 2020 06:18:34 +0000
Subject: [issue41368] Allow compiling Python with llvm-clang on Windows.
In-Reply-To: <1595441637.36.0.539445300031.issue41368@roundup.psfhosted.org>
Message-ID: <1595485114.13.0.563699913062.issue41368@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
nosy: +Jeffrey.Kintscher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41368>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:23:33 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Thu, 23 Jul 2020 06:23:33 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1595485413.93.0.794773665781.issue37095@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
nosy: +Jeffrey.Kintscher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:26:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 06:26:06 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595485566.32.0.0514402309819.issue4630@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4cf7afcefcd1eb1ab233ed4523eb2b3bbf599c81 by Miss Islington (bot) in branch '3.9':
bpo-4630: Fix errors in Lib/idlelib/NEWS.txt (GH-21594)
https://github.com/python/cpython/commit/4cf7afcefcd1eb1ab233ed4523eb2b3bbf599c81


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Thu Jul 23 03:02:28 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Thu, 23 Jul 2020 07:02:28 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595487748.61.0.721980514891.issue41350@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
nosy: +Jeffrey.Kintscher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Thu Jul 23 03:46:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 07:46:21 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595490381.73.0.991016561409.issue4630@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +20738
pull_request: https://github.com/python/cpython/pull/21599

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Thu Jul 23 03:51:44 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 23 Jul 2020 07:51:44 +0000
Subject: [issue41374] socket.TCP_* no longer available with cygwin 3.1.6+
Message-ID: <1595490704.07.0.649120374256.issue41374@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

The TCP macros are provided by netinet/tcp.h, which for some reason is skipped here: https://github.com/python/cpython/blob/592527f3ee59616eca2bd1da771f7c14cee808d5/Modules/socketmodule.h#L11

Until cygwin 3.1.6 these macros were also provided by sys/socket.h, but this got removed in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=e037192b505b4f233fca9a6deafc9797210f6693

This leads to socket.TCP_NODELAY for example not being available anymore.

git blame leads me to https://github.com/python/cpython/commit/b5daaed30d7c54ba1f516289f3a7a30a864133af introducing this special case, which isn't very helpful. I'd suggest to just remove the cygwin check and always include it (which works fine on my machine)

Downstream bug report for extra context: https://github.com/msys2/MSYS2-packages/issues/2050

----------
components: Build
messages: 374126
nosy: lazka
priority: normal
severity: normal
status: open
title: socket.TCP_* no longer available with cygwin 3.1.6+
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41374>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:16:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 08:16:21 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595492181.04.0.600984471442.issue41373@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

So loading an externally created blank file (on any system) results in None.  File=>New must set eol_convention, I presume to the same default.  Before I got the traceback, I though it might be an issue with the Windows utf-8 BOM being added.

3.9.0rc1 is due August 10.  It should have fix and new tests.

----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:18:15 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 08:18:15 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595492295.11.0.554777926568.issue4630@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 29df301a9236cbae06762d9569e56197d3f5e6ee by Terry Jan Reedy in branch '3.8':
 [3.8] bpo-4630: Fix errors in Lib/idlelib/NEWS.txt (GH-21594)
https://github.com/python/cpython/commit/29df301a9236cbae06762d9569e56197d3f5e6ee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:20:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2020 08:20:12 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1595492412.75.0.51880617115.issue4630@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:28:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 23 Jul 2020 08:28:12 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
In-Reply-To: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>
Message-ID: <1595492892.75.0.929438136029.issue41365@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> it fails with this error means you're running a virtual-environment launcher instead of a base Python executable.

Exactly. It sounds like you probably searched for pythonw.exe and found the one in Lib/venv/scripts/nt instead of the actual one.

The default association should go to pyw.exe, which is likely in your C:\Windows directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:39:18 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Jul 2020 08:39:18 +0000
Subject: [issue41366] sign-conversion warning in 3.9 beta
In-Reply-To: <1595389781.15.0.650471141646.issue41366@roundup.psfhosted.org>
Message-ID: <1595493558.09.0.775367963338.issue41366@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 680254a8dc64e3ada00f88a7c42d41eb02108353 by Henry Schreiner in branch 'master':
bpo-41366: Fix clang warning for sign conversion (GH-21592)
https://github.com/python/cpython/commit/680254a8dc64e3ada00f88a7c42d41eb02108353


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41366>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:39:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 08:39:45 +0000
Subject: [issue41366] sign-conversion warning in 3.9 beta
In-Reply-To: <1595389781.15.0.650471141646.issue41366@roundup.psfhosted.org>
Message-ID: <1595493585.77.0.0417407090415.issue41366@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20739
pull_request: https://github.com/python/cpython/pull/21600

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41366>
_______________________________________

From report at bugs.python.org  Thu Jul 23 04:59:38 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 08:59:38 +0000
Subject: [issue41366] sign-conversion warning in 3.9 beta
In-Reply-To: <1595389781.15.0.650471141646.issue41366@roundup.psfhosted.org>
Message-ID: <1595494778.27.0.677969564758.issue41366@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e8dda907fbeb957436d2662714d993b073be55bb by Miss Islington (bot) in branch '3.9':
bpo-41366: Fix clang warning for sign conversion (GH-21592)
https://github.com/python/cpython/commit/e8dda907fbeb957436d2662714d993b073be55bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41366>
_______________________________________

From report at bugs.python.org  Thu Jul 23 05:01:18 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Jul 2020 09:01:18 +0000
Subject: [issue41366] sign-conversion warning in 3.9 beta
In-Reply-To: <1595389781.15.0.650471141646.issue41366@roundup.psfhosted.org>
Message-ID: <1595494878.3.0.221410450434.issue41366@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Thank you.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41366>
_______________________________________

From report at bugs.python.org  Thu Jul 23 08:34:32 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 23 Jul 2020 12:34:32 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595507672.84.0.925466033206.issue41335@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

It's possible that RPi.GPIO (or another C extension) is mis-managing reference counts, resulting in it freeing or trying to free an object at the wrong time.  

If that object is a common value, or the branch that causes the refcount issue is uncommon, it may take many millions of cycles for the problem to occur.

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Thu Jul 23 08:50:45 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 23 Jul 2020 12:50:45 +0000
Subject: [issue41367] Popen Timeout raised on 3.6 but not on 3.8
In-Reply-To: <1595407379.06.0.696065311763.issue41367@roundup.psfhosted.org>
Message-ID: <1595508645.71.0.66806403564.issue41367@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Joan, is that your *actual* password in the example code?  If so, I'd recommend changing it wherever you've used it.

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41367>
_______________________________________

From report at bugs.python.org  Thu Jul 23 09:09:20 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 23 Jul 2020 13:09:20 +0000
Subject: [issue41365] Python Launcher is sorry to say... No pyvenv.cfg file
In-Reply-To: <1595388528.0.0.559799161472.issue41365@roundup.psfhosted.org>
Message-ID: <1595509760.16.0.24638284207.issue41365@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The default association should go to pyw.exe, which is likely in 
> your C:\Windows directory.

However, don't browse for pyw.exe. That will create a new progid that doesn't support command-line arguments or a shell drop handler. You should select the Python app from the list that shows a rocket/shuttle being launched on its icon. If it isn't shown or doesn't work properly, try repairing your installation of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41365>
_______________________________________

From report at bugs.python.org  Thu Jul 23 10:02:32 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 23 Jul 2020 14:02:32 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595512952.41.0.858606056159.issue41335@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

int_free() and small_ints in the traceback likely point to a reference counting issue for small integers in range of -5 to +256. These integers are cached and should never get freed in the middle of a process.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Thu Jul 23 10:15:20 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 23 Jul 2020 14:15:20 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595513720.81.0.346193527845.issue41335@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Correction, _int_free() is an internal function of malloc().

small_ints.lto_priv+72 looks like deallocation of an integer object at location +72. This is either int 4 (on 64bit platforms) or int 13 (on 32bit platforms):

>>> NSMALLNEGINTS = 5
>>> (4 + NSMALLNEGINTS) * 8
72
>>> (13 + NSMALLNEGINTS) * 4
72

Could you please report the issue with RPi package owner? This looks like a bug in a 3rd party module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:07:20 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 23 Jul 2020 15:07:20 +0000
Subject: [issue41375] `mode` security concern
Message-ID: <1595516840.65.0.992254225297.issue41375@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

import os
import stat
import os.path


def problem(tmp_path):
    # result:
    # -------
    # check: False
    # mode: 416

    # create temp file
    fd = os.open(tmp_path, os.O_CREAT, 0o660)
    os.close(fd)

    # Directory is effected as well
    # os.mkdir(tmp_path, 0o660)


def solution(tmp_path):
    # result:
    # -------
    # check: True
    # mode: 432

    old_umask = os.umask(0)

    # create temp file
    fd = os.open(tmp_path, os.O_CREAT, 0o660)
    os.close(fd)

    # create temp dir
    # os.mkdir(tmp_path, 0o660)

    os.umask(old_umask)


def main():
    tmp_path = '_testing-chmod'

    problem(tmp_path)
    # solution(tmp_path)

    try:
        s = os.stat(tmp_path)
        mode = stat.S_IMODE(s.st_mode)
        print('check:', mode == 0o660)
        print('mode:', mode)  # this should be: 432
    finally:
        # delete temp file
        try:
            os.unlink(tmp_path)
        except IsADirectoryError:
            os.rmdir(tmp_path)


if __name__ == '__main__':
    main()


This result is not same for all os and distro, on multiple linux system for example the results will be different. I think Python should account for such behavior by default as it can lead to file/dir creation with security issues.

----------
components: IO
messages: 374138
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: `mode` security concern

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41375>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:22:11 2020
From: report at bugs.python.org (Phil Elson)
Date: Thu, 23 Jul 2020 15:22:11 +0000
Subject: [issue41376] site.getusersitepackages() incorrectly claims that
 PYTHONNOUSERSITE is respected
Message-ID: <1595517731.78.0.301651868818.issue41376@roundup.psfhosted.org>


New submission from Phil Elson <pelson.pub at gmail.com>:

The documentation for site.getusersitepackages() states at https://docs.python.org/3.10/library/site.html#site.getusersitepackages:

Return the path of the user-specific site-packages directory, USER_SITE. If it is not initialized yet, this function will also set it, respecting PYTHONNOUSERSITE and USER_BASE.


Yet the implementation does not agree:


```
$ python  -c "import site; print(site.getusersitepackages())"
/home/user/.local/lib/python3.7/site-packages

$ PYTHONNOUSERSITE=1 python -c "import site; print(site.getusersitepackages())"
/home/user/.local/lib/python3.7/site-packages
```

(same result for -s and -I flags)

----------
assignee: docs at python
components: Documentation
messages: 374139
nosy: docs at python, pelson
priority: normal
severity: normal
status: open
title: site.getusersitepackages() incorrectly claims that PYTHONNOUSERSITE is respected
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/issue41376>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:27:48 2020
From: report at bugs.python.org (Phil Elson)
Date: Thu, 23 Jul 2020 15:27:48 +0000
Subject: [issue41376] site.getusersitepackages() incorrectly claims that
 PYTHONNOUSERSITE is respected
In-Reply-To: <1595517731.78.0.301651868818.issue41376@roundup.psfhosted.org>
Message-ID: <1595518068.57.0.192297953802.issue41376@roundup.psfhosted.org>


Change by Phil Elson <pelson.pub at gmail.com>:


----------
keywords: +patch
pull_requests: +20740
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21602

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41376>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:34:40 2020
From: report at bugs.python.org (William Pickard)
Date: Thu, 23 Jul 2020 15:34:40 +0000
Subject: [issue41358] Unable to uninstall Python launcher using command line
In-Reply-To: <1595327997.84.0.414162156618.issue41358@roundup.psfhosted.org>
Message-ID: <1595518480.05.0.0807422936609.issue41358@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

I think on Windows, the Python Launcher is a separate install entity.

You can verify this under Control Panel -> Uninstall Program and Features.

----------
nosy: +WildCard65

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41358>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:46:37 2020
From: report at bugs.python.org (Ramon)
Date: Thu, 23 Jul 2020 15:46:37 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1595519197.0.0.786778168459.issue38946@roundup.psfhosted.org>


Change by Ramon <r.garciaprieto30 at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:48:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2020 15:48:14 +0000
Subject: [issue41375] `mode` security concern
In-Reply-To: <1595516840.65.0.992254225297.issue41375@roundup.psfhosted.org>
Message-ID: <1595519294.53.0.917931991006.issue41375@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is expected behavior on Posix system. See https://pubs.opengroup.org/onlinepubs/9699919799/functions/umask.html

What is the problem?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41375>
_______________________________________

From report at bugs.python.org  Thu Jul 23 12:09:34 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Jul 2020 16:09:34 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1595520574.7.0.502852260253.issue38946@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Ramon, I am not sure why you closed this issue. Perhaps it may no longer be a problem for you, but it has not yet been resolved for users of the python.org macOS installers.

----------
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Thu Jul 23 12:34:25 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 23 Jul 2020 16:34:25 +0000
Subject: [issue41375] `mode` security concern
In-Reply-To: <1595516840.65.0.992254225297.issue41375@roundup.psfhosted.org>
Message-ID: <1595522065.62.0.159257355334.issue41375@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

I am closing this as its not a issue anymore... I was trying to solve a problem that has become a core feature!

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41375>
_______________________________________

From report at bugs.python.org  Thu Jul 23 14:01:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2020 18:01:05 +0000
Subject: [issue41375] `mode` security concern
In-Reply-To: <1595516840.65.0.992254225297.issue41375@roundup.psfhosted.org>
Message-ID: <1595527265.2.0.244259322145.issue41375@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41375>
_______________________________________

From report at bugs.python.org  Thu Jul 23 14:21:26 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 23 Jul 2020 18:21:26 +0000
Subject: [issue41374] socket.TCP_* no longer available with cygwin 3.1.6+
In-Reply-To: <1595490704.07.0.649120374256.issue41374@roundup.psfhosted.org>
Message-ID: <1595528486.0.0.264721660964.issue41374@roundup.psfhosted.org>


Change by Christoph Reiter <reiter.christoph at gmail.com>:


----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41374>
_______________________________________

From report at bugs.python.org  Thu Jul 23 15:45:17 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2020 19:45:17 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595533517.06.0.571175979654.issue41317@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 0dd98c2d00a75efbec19c2ed942923981bc06683 by Alex Gr?nholm in branch 'master':
bpo-41317: Remove reader on cancellation in asyncio.loop.sock_accept() (#21595)
https://github.com/python/cpython/commit/0dd98c2d00a75efbec19c2ed942923981bc06683


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Thu Jul 23 15:45:29 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 19:45:29 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595533529.96.0.8524955476.issue41317@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20742
pull_request: https://github.com/python/cpython/pull/21603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Thu Jul 23 16:02:57 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jul 2020 20:02:57 +0000
Subject: [issue41317] sock_accept() does not remove server socket reader on
 cancellation
In-Reply-To: <1594937525.52.0.117066426287.issue41317@roundup.psfhosted.org>
Message-ID: <1595534577.08.0.324429692785.issue41317@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4ff8e5ba4fef7f7d0fc1b1872ccb91bc3fd1294d by Miss Islington (bot) in branch '3.9':
bpo-41317: Remove reader on cancellation in asyncio.loop.sock_accept() (GH-21595)
https://github.com/python/cpython/commit/4ff8e5ba4fef7f7d0fc1b1872ccb91bc3fd1294d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41317>
_______________________________________

From report at bugs.python.org  Thu Jul 23 16:46:27 2020
From: report at bugs.python.org (jakirkham)
Date: Thu, 23 Jul 2020 20:46:27 +0000
Subject: [issue41377] memoryview of str (unicode)
Message-ID: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>


New submission from jakirkham <jakirkham at gmail.com>:

When working with lower level C/C++ code, the Python Buffer Protocol[1] has been immensely useful as it allows common Python `bytes`-like objects to expose the underlying memory buffer in a pointer that C/C++ code can easily work with zero-copy. In fact `memoryview` objects can be quite handy when facilitating coercion of Python objects supporting the Python Buffer Protocol to something that Python and/or C/C++ code can use easily. This works with several Python objects, many Python APIs, and in is relied on heavily by many performance conscious 3rd party libraries.

However one object that gets a lot of use in Python that doesn't support this API is the Python `str` (previously `unicode`) object (see code below).

```python
In [1]: s = "Hello World!"                                                      

In [2]: mv = memoryview(s)                                                      
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-3403c1ca3811> in <module>
----> 1 mv = memoryview(s)

TypeError: memoryview: a bytes-like object is required, not 'str'
```

The canonical answer today is [to encode to `bytes` first]( https://stackoverflow.com/a/54449407 ) and decode to `str` later. While this is ok for a smallish piece of text, it can start to slowdown considerably for larger pieces of text. So being able to skip this encode/decode step can be quite impactful.

```python
In [1]: s = "Hello World!"                                                      

In [2]: %timeit s.encode();                                                     
54.9 ns ? 0.0788 ns per loop (mean ? std. dev. of 7 runs, 10000000 loops each)

In [3]: s = 100_000_000 * "Hello World!"                                        

In [4]: %timeit s.encode();                                                     
729 ms ? 1.23 ms per loop (mean ? std. dev. of 7 runs, 1 loop each)
```

AIUI (though I could be misunderstanding things) `str` objects do use some kind of typed array of unicode characters (either 16-bit narrow or 32-bit wide). So it seems like it *should* be possible to expose this as a 1-D contiguous array that C/C++ code could use. Though I may be misunderstanding how `str`s actually work under-the-hood (if so apologies).

It would be quite helpful to bypass this encoding/decoding step and instead work directly with the underlying buffer in these situations where C/C++ is involved to help performance critical code.

[1]: https://docs.python.org/3/c-api/buffer.html

----------
components: Library (Lib)
messages: 374147
nosy: jakirkham
priority: normal
severity: normal
status: open
title: memoryview of str (unicode)
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Thu Jul 23 17:51:21 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 23 Jul 2020 21:51:21 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595541081.43.0.376554868386.issue41377@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> AIUI (though I could be misunderstanding things) `str` objects do use some kind of typed array of unicode characters (either 16-bit narrow or 32-bit wide). 

It's somewhat more complicated. The string data is stored differently depending on the maximum code point in the string. See PEP 393.

The "kind" field describes this as:
1 byte (Latin-1)
2 byte (UCS-2)
4 byte (UCS-4)

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Thu Jul 23 18:06:11 2020
From: report at bugs.python.org (jakirkham)
Date: Thu, 23 Jul 2020 22:06:11 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595541971.41.0.692146593478.issue41377@roundup.psfhosted.org>


jakirkham <jakirkham at gmail.com> added the comment:

Thanks for the clarification, Eric! :)

Is this the sort of thing that we could capture in the `format`[1] field (like with `"B"`, `"H"`, and `"I"`[2]) or are there potential issues there?

[1]: https://docs.python.org/3/c-api/buffer.html#c.Py_buffer.format
[2]: https://docs.python.org/3/library/struct.html#format-characters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Thu Jul 23 18:09:32 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Jul 2020 22:09:32 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1595542172.79.0.439247064824.issue40841@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This looks like a useful addition. I hope someone will take up the review!

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Thu Jul 23 18:18:29 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Thu, 23 Jul 2020 22:18:29 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595542709.42.0.915548836189.issue41350@roundup.psfhosted.org>


Jeffrey Kintscher <websurfer at surf2c.net> added the comment:

It looks like a copy of the zip_file object is getting created, probably by the Path constructor:

    zip_path = Path(zip_file, "file-a")

When return is invoked, the copy still has a reference to the now closed bytes_io object which causes the ValueError exception when ZipFile.__del__() calls ZipFile.close().  This is definitely a bug.  I'll take a crack at fixing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Thu Jul 23 18:30:05 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 23 Jul 2020 22:30:05 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595543405.92.0.608910807273.issue41377@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think there's a python-level api to find out the "kind", but I can't say I've looked closely. And there are no doubt problems with doing so and alternate implementations other than CPython. I'm not sure we want to expose this implementation detail, but maybe it's the case that all implementations could expose this. For example, JPython could always just say "I'm UCS-2", or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Thu Jul 23 19:59:02 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Jul 2020 23:59:02 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1595548742.14.0.521447361466.issue41182@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

?ukasz, what do you think of backporting this to 3.9?

----------
nosy: +gvanrossum, lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:10:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jul 2020 00:10:10 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595549410.72.0.655298767121.issue41377@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:25:43 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2020 00:25:43 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595550343.8.0.843085453508.issue41377@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think we can close this.  AFAICT, if we exposed the raw internal object with a memory view, there would be no practical way to use the data without a user having to substantially recreate the logic already present in encode() and the other string methods.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:42:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2020 00:42:59 +0000
Subject: [issue41378] IDLE EOL convention not set on a empty file
Message-ID: <1595551379.62.0.314572347741.issue41378@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

I think this is a new bug, present in Python 3.8.5 but not present in 3.8.3.

Steps to reproduce:

    * $ touch xyzpdq.py             # Creates new file, zero bytes in length
    * $ python3.8 -m idlelib.idle xyzdpq.py
    * Enter text:   print('hello world')
    * Attempt to save the file with Cmd-S
    * This seems to be unrecoverable and results
      in losing all the code that was entered.

---------------- example session ---------------
~ $ cd tmp
~/tmp $ touch qwerty.py
~/tmp $ python3.8 -m idlelib.idle qwerty.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/tkinter/__init__.py", line 1883, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/multicall.py", line 176, in handler
    r = l[i](event)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/iomenu.py", line 200, in save
    if self.writefile(self.filename):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/iomenu.py", line 232, in writefile
    text = self.fixnewlines()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/iomenu.py", line 252, in fixnewlines
    text = text.replace("\n", self.eol_convention)
TypeError: replace() argument 2 must be str, not None

----------
assignee: terry.reedy
components: IDLE
keywords: 3.8regression, 3.9regression
messages: 374155
nosy: rhettinger, terry.reedy
priority: high
severity: normal
status: open
title: IDLE EOL convention not set on a empty file
type: crash
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41378>
_______________________________________

From report at bugs.python.org  Thu Jul 23 22:28:51 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 24 Jul 2020 02:28:51 +0000
Subject: [issue41378] IDLE EOL convention not set on a empty file
In-Reply-To: <1595551379.62.0.314572347741.issue41378@roundup.psfhosted.org>
Message-ID: <1595557731.01.0.246131938272.issue41378@roundup.psfhosted.org>


Emmanuel Arias <eamanu at yaerobi.com> added the comment:

Hello everybody!

When a new file is loaded, the current loadfile read for the newline to set
the eol_convention. As does not exist for a empty file a None is saved and
for that reason the exception is raised

If you consider that this patch is correct I cant submit a PR

Cheers

----------
keywords: +patch
nosy: +eamanu
Added file: https://bugs.python.org/file49334/0001-Fix-eol_convention-when-file-does-not-exist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41378>
_______________________________________

From report at bugs.python.org  Thu Jul 23 23:38:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2020 03:38:47 +0000
Subject: [issue41378] IDLE EOL convention not set on a empty file
In-Reply-To: <1595551379.62.0.314572347741.issue41378@roundup.psfhosted.org>
Message-ID: <1595561927.7.0.0508912766186.issue41378@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41378>
_______________________________________

From report at bugs.python.org  Thu Jul 23 23:41:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2020 03:41:29 +0000
Subject: [issue41378] IDLE EOL convention not set on a empty file
In-Reply-To: <1595551379.62.0.314572347741.issue41378@roundup.psfhosted.org>
Message-ID: <1595562089.04.0.152097226385.issue41378@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This may have been caused by https://github.com/python/cpython/commit/c3fa7534c7173d338880a1727f17795670518610 for https://bugs.python.org/issue41378

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41378>
_______________________________________

From report at bugs.python.org  Fri Jul 24 00:25:58 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2020 04:25:58 +0000
Subject: [issue41378] IDLE EOL convention not set on a empty file
In-Reply-To: <1595551379.62.0.314572347741.issue41378@roundup.psfhosted.org>
Message-ID: <1595564758.61.0.334614284404.issue41378@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41378>
_______________________________________

From report at bugs.python.org  Fri Jul 24 00:27:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2020 04:27:45 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595564865.92.0.964234470845.issue41377@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Raymond.

Also, it could not help to caught bugs when you get a string instead expected bytes object. It may "work" in tests while string is ASCII, but fail miserably on real-world non-ASCII data.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Fri Jul 24 01:50:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2020 05:50:02 +0000
Subject: [issue41378] IDLE EOL convention not set on a empty file
In-Reply-To: <1595551379.62.0.314572347741.issue41378@roundup.psfhosted.org>
Message-ID: <1595569802.73.0.542297578715.issue41378@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is a duplicate of issue41373 (and the problem is not only with empty files).

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: edit/save files created by Windows Explorer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41378>
_______________________________________

From report at bugs.python.org  Fri Jul 24 02:01:23 2020
From: report at bugs.python.org (Vignesh Rajendran)
Date: Fri, 24 Jul 2020 06:01:23 +0000
Subject: [issue41379] Configparser is not reading Indended Sections as
 Mentioned in Docs
Message-ID: <1595570483.9.0.509189951267.issue41379@roundup.psfhosted.org>


New submission from Vignesh Rajendran <vickygum95 at gmail.com>:

https://github.com/jaraco/configparser/issues/55

Please check the Bug is raised also in Github,

Sections can be intended is specified in the documentation.

When I read the indented section, its throwing section not found an error in python 3.8

as per Documentation https://docs.python.org/3/library/configparser.html
[You can use comments]
like this
; or this

    [Sections Can Be Indented]
    can_values_be_as_well = True
    does_that_mean_anything_special = False
    purpose = formatting for readability
but this is not working.
check this https://stackoverflow.com/questions/62833787/how-to-read-indentated-sections-with-python-configparser/62836972?noredirect=1#comment111176192_62836972

if i read an indented section, its showing section not found.

my file:
[section]
a = 0.3

    [subsection]
    b = 123
import configparser
conf = configparser.ConfigParser()
conf.read("./test.conf")
a = conf['section']['a']
print(a)

Output of a:

0.3

[subsection]
b = 123

Expected a : 0.3 only

But Section b is not found

----------
messages: 374160
nosy: Vignesh Rajendran
priority: normal
severity: normal
status: open
title: Configparser is not reading Indended Sections as Mentioned in Docs
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41379>
_______________________________________

From report at bugs.python.org  Fri Jul 24 02:03:46 2020
From: report at bugs.python.org (Vignesh Rajendran)
Date: Fri, 24 Jul 2020 06:03:46 +0000
Subject: [issue41379] Configparser is not reading Indended Sections as
 Mentioned in Docs
In-Reply-To: <1595570483.9.0.509189951267.issue41379@roundup.psfhosted.org>
Message-ID: <1595570626.13.0.199243505946.issue41379@roundup.psfhosted.org>


Change by Vignesh Rajendran <vickygum95 at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41379>
_______________________________________

From report at bugs.python.org  Fri Jul 24 02:17:08 2020
From: report at bugs.python.org (hap)
Date: Fri, 24 Jul 2020 06:17:08 +0000
Subject: [issue41358] Unable to uninstall Python launcher using command line
In-Reply-To: <1595327997.84.0.414162156618.issue41358@roundup.psfhosted.org>
Message-ID: <1595571428.2.0.700740967077.issue41358@roundup.psfhosted.org>


hap <ahmedparvez321 at gmail.com> added the comment:

Run msiexec.exe /x {339192BE-2520-4C34-89DF-81CF98EB7E6C} /qn+ fixed it

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41358>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:03:35 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 24 Jul 2020 07:03:35 +0000
Subject: [issue41379] Configparser is not reading Indended Sections as
 Mentioned in Docs
In-Reply-To: <1595570483.9.0.509189951267.issue41379@roundup.psfhosted.org>
Message-ID: <1595574215.47.0.788802208165.issue41379@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

In your example you're instantiating ConfigParser with default parameters, meaning empty_lines_in_values equals True, which leads to key "a" consuming everything on the following indented lines. If you're were to specify False as the value for empty_lines_in_values, you'd see the desired behaviour.

The examples in documentation work just fine, as long as you copy them exactly. The reason they do is that there isn't a final value in the non-indented section, but only comments. In any case empty_lines_in_values is what you should be using.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41379>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:13:47 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Fri, 24 Jul 2020 07:13:47 +0000
Subject: [issue41380] Create snake.py
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595574827.01.0.419860082066.issue41380@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:13:31 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Fri, 24 Jul 2020 07:13:31 +0000
Subject: [issue41380] Create snake.py
Message-ID: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>


New submission from Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:

Created simple and basic snake game using python turtle!
We use the simplest algorithm to made it!
It will be good example for beginners!

----------
components: Tkinter
messages: 374163
nosy: Ehsonjon Gadoev
priority: normal
severity: normal
status: open
title: Create snake.py
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:15:07 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Fri, 24 Jul 2020 07:15:07 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
In-Reply-To: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>
Message-ID: <1595574907.77.0.734515564689.issue41280@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
nosy: +Ehsonjon Gadoev
nosy_count: 4.0 -> 5.0
pull_requests: +20743
pull_request: https://github.com/python/cpython/pull/21582

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:17:23 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Fri, 24 Jul 2020 07:17:23 +0000
Subject: [issue41380] Create snake.py
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595575043.0.0.7431145152.issue41380@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
keywords: +patch
pull_requests: +20744
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21582

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:32:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2020 07:32:25 +0000
Subject: [issue41280] lru_cache on 0-arity functions should default to
 maxsize=None
In-Reply-To: <1594507572.96.0.37330867627.issue41280@roundup.psfhosted.org>
Message-ID: <1595575945.37.0.826932014287.issue41280@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -20743

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41280>
_______________________________________

From report at bugs.python.org  Fri Jul 24 04:37:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2020 08:37:40 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595579860.55.0.404074749363.issue41373@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Bumping-up the priority.  Today, I and a (virtual) room full of engineers simultaneously hit this problem and we all lost work.  See issue41378

----------
nosy: +rhettinger
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:08:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jul 2020 09:08:04 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595581684.37.0.766045804796.issue41373@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Raymond, I tested patch today and expect to apply it (without unittests yet) tomorrow, so will be in 3.9.0rc1 abd 3.8.6.  In the meanwhile, either create new files within IDLE (File=>NEW) or add "isinstance(self.eol_convention, str) and " after 'if' on line 251 of idlelib/iomenu.py, just before the line in the traceback.

The added check will be put elsewhere by the patch, but it should work on 251.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:15:38 2020
From: report at bugs.python.org (Antoine Pietri)
Date: Fri, 24 Jul 2020 09:15:38 +0000
Subject: [issue38306] High level API for loop.run_in_executor(None, ...)?
In-Reply-To: <1569681785.01.0.799144749415.issue38306@roundup.psfhosted.org>
Message-ID: <1595582138.35.0.638239336013.issue38306@roundup.psfhosted.org>


Antoine Pietri <antoine.pietri1 at gmail.com> added the comment:

Yeah I'm pretty sure this solves it: https://github.com/python/cpython/pull/20143

Closing the issue, thanks.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38306>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:46:40 2020
From: report at bugs.python.org (Anand Tripathi)
Date: Fri, 24 Jul 2020 09:46:40 +0000
Subject: [issue41381] Google chat handler in Logging module
Message-ID: <1595584000.4.0.416616508258.issue41381@roundup.psfhosted.org>


Change by Anand Tripathi <anand.tripathi507 at gmail.com>:


----------
nosy: anandtripathi5
priority: normal
severity: normal
status: open
title: Google chat handler in Logging module
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:48:11 2020
From: report at bugs.python.org (Anand Tripathi)
Date: Fri, 24 Jul 2020 09:48:11 +0000
Subject: [issue41381] Google chat handler in Logging module
Message-ID: <1595584091.55.0.744768850804.issue41381@roundup.psfhosted.org>


New submission from Anand Tripathi <anand.tripathi507 at gmail.com>:

Google chat handler is not there in logging module of python.

How can I contribute to this enhancement, is there any way possible!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:50:03 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 24 Jul 2020 09:50:03 +0000
Subject: [issue41381] Google chat handler in Logging module
In-Reply-To: <1595584091.55.0.744768850804.issue41381@roundup.psfhosted.org>
Message-ID: <1595584203.13.0.479309356475.issue41381@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Anand, this is very specific to one product and I don't think the core team will take the burden to maintain to as it may be too specific. You could create a package and publish it on Pypi so others can use it thought.

----------
components: +Library (Lib)
nosy: +remi.lapeyre
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Fri Jul 24 06:05:45 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Fri, 24 Jul 2020 10:05:45 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595585145.57.0.818818862354.issue41350@roundup.psfhosted.org>


Jeffrey Kintscher <websurfer at surf2c.net> added the comment:

I created a simpler test case that exercises the buggy code.  The problem can be reproduced by passing ZipFile.__init__() a file-like object with the write flag (mode "w") and then closing the file-like object before calling ZipFile.close().

The exception being triggered by the call to ZipFile.__del__() is a side-effect because all ZipFile.__del__() does is call ZipFile.close().



import io
from zipfile import ZipFile

bytes_io = io.BytesIO()
zip_file = ZipFile(bytes_io, mode="w")
bytes_io.close()
zip_file.close()  # throws ValueError

----------
Added file: https://bugs.python.org/file49336/zipfile_close_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 06:08:28 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Fri, 24 Jul 2020 10:08:28 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595585308.23.0.699455069511.issue41350@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 06:14:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jul 2020 10:14:50 +0000
Subject: [issue41381] Google chat handler in Logging module
In-Reply-To: <1595584091.55.0.744768850804.issue41381@roundup.psfhosted.org>
Message-ID: <1595585690.62.0.730819222334.issue41381@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Fri Jul 24 06:34:34 2020
From: report at bugs.python.org (Rajarishi Devarajan)
Date: Fri, 24 Jul 2020 10:34:34 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595586874.31.0.2935462885.issue41350@roundup.psfhosted.org>


Rajarishi Devarajan <rishi93dev at gmail.com> added the comment:

Hi all, I have a working patch for this. Could I submit it for review ?

----------
nosy: +rishi93

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 07:18:36 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 24 Jul 2020 11:18:36 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595589516.98.0.717742779655.issue41373@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 07:27:35 2020
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Fri, 24 Jul 2020 11:27:35 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595590055.96.0.0439789991137.issue41350@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
keywords: +patch
pull_requests: +20745
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21604

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 07:36:38 2020
From: report at bugs.python.org (E. Paine)
Date: Fri, 24 Jul 2020 11:36:38 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595590598.47.0.579266193129.issue41380@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

@Ehsonjon Gadoev, thank you for the patch. I would appreciate if you could explain in a little more detail why you think adding this example would be beneficial to the CPython project, as it would inevitably increase the maintenance load on the core-devs (please don't take this personally: any new code would do this).

----------
components: +Library (Lib) -Tkinter
nosy: +epaine, gregorlingl, willingc
title: Create snake.py -> Add snake example to turtledemo
type:  -> enhancement
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Fri Jul 24 09:13:02 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 13:13:02 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595596382.52.0.12852219243.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

On Fedora32/PPC64LE (5.7.9-200.fc32.ppc64le), with little change:
  libc = CDLL('/usr/lib64/libc.so.6')
I get the correct answer:
b'def'
b'def'
b'def'
# python3 --version
Python 3.8.3
libffi : 3.1-24


On Fedora32/x86_64 (5.7.9-200.fc32.x86_64), with a little change:
  libc = CDLL('/usr/lib64/libc-2.31.so')
that crashes:
b'def'
Segmentation fault (core dumped)
# python3 --version
Python 3.8.3
libffi : 3.1-24


AIX : libffi-3.2.1
On AIX 7.2, with Python 3.8.5 compiled with XLC v13, in 64bit:
b'def'
b'def'
None
On AIX 7.2, with Python 3.8.5 compiled with GCC 8.4, in 64bit:
b'def'
b'def'
None

On AIX 7.2, with Python 3.8.5 compiled with XLC v13, in 32bit:
  ( libc = CDLL('libc.a(shr.o)') )
b'def'
b'def'
b'def'
On AIX 7.2, with Python 3.8.5 compiled with GCC 8.4, in 32bit:
b'def'
b'def'
b'def'

Preliminary conclusions:
 - this is a 64bit issue on AIX and it is independent of the compiler
 - it is worse on Fedora/x86_64
 - it works perfectly on Fedora/PPC64LE
what a mess.

----------
nosy: +T.Rex

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 09:13:29 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 24 Jul 2020 13:13:29 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1595596409.08.0.675874235573.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +20746
pull_request: https://github.com/python/cpython/pull/21605

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Jul 24 09:36:14 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 13:36:14 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595597774.54.0.238087193875.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

Fedora32/x86_64

[root at destiny10 tmp]# gdb /usr/bin/python3.8 core
...
Core was generated by `python3 ./Pb.py'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f898a02a1d8 in __memchr_sse2 () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install python3-3.8.3-2.fc32.x86_64
(gdb) where
#0  0x00007f898a02a1d8 in __memchr_sse2 () from /lib64/libc.so.6
#1  0x00007f898982caf0 in ffi_call_unix64 () from /lib64/libffi.so.6
#2  0x00007f898982c2ab in ffi_call () from /lib64/libffi.so.6
#3  0x00007f8989851ef1 in _ctypes_callproc.cold () from /usr/lib64/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so
#4  0x00007f898985ba2f in PyCFuncPtr_call () from /usr/lib64/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so
#5  0x00007f8989d6c7a1 in _PyObject_MakeTpCall () from /lib64/libpython3.8.so.1.0
#6  0x00007f8989d69111 in _PyEval_EvalFrameDefault () from /lib64/libpython3.8.so.1.0
#7  0x00007f8989d62ec4 in _PyEval_EvalCodeWithName () from /lib64/libpython3.8.so.1.0
#8  0x00007f8989dde109 in PyEval_EvalCodeEx () from /lib64/libpython3.8.so.1.0
#9  0x00007f8989dde0cb in PyEval_EvalCode () from /lib64/libpython3.8.so.1.0
#10 0x00007f8989dff028 in run_eval_code_obj () from /lib64/libpython3.8.so.1.0
#11 0x00007f8989dfe763 in run_mod () from /lib64/libpython3.8.so.1.0
#12 0x00007f8989cea81b in PyRun_FileExFlags () from /lib64/libpython3.8.so.1.0
#13 0x00007f8989cea19d in PyRun_SimpleFileExFlags () from /lib64/libpython3.8.so.1.0
#14 0x00007f8989ce153c in Py_RunMain.cold () from /lib64/libpython3.8.so.1.0
#15 0x00007f8989dd1bf9 in Py_BytesMain () from /lib64/libpython3.8.so.1.0
#16 0x00007f8989fb7042 in __libc_start_main () from /lib64/libc.so.6
#17 0x0000557a1f3c407e in _start ()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 09:55:13 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 13:55:13 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595598913.52.0.0966073324518.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

On AIX:

root at castor4## gdb /opt/freeware/bin/python3
...
(gdb) run -m pdb Pb.py
...
(Pdb) n
b'def'
> /home2/freeware/src/packages/BUILD/Python-3.8.5/32bit/Pb.py(35)<module>()
-> print(
(Pdb) n
> /home2/freeware/src/packages/BUILD/Python-3.8.5/32bit/Pb.py(36)<module>()
-> CFUNCTYPE(c_char_p, MemchrArgsHack2,
(Pdb)
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 1]
0x090000000016426c in __fd_select () from /usr/lib/libc.a(shr_64.o)
(gdb) b ffi_call
Breakpoint 1 at 0x1217918
(gdb) c
...
(Pdb) n

Thread 2 hit Breakpoint 1, 0x0900000001217918 in ffi_call () from /opt/freeware/lib/libffi.a(libffi.so.6)
(gdb) where
#0  0x0900000001217918 in ffi_call () from /opt/freeware/lib/libffi.a(libffi.so.6)
#1  0x0900000001217780 in ffi_prep_cif_machdep () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2  0x0900000001216fb8 in ffi_prep_cif_var () from /opt/freeware/lib/libffi.a(libffi.so.6)
......

(gdb) b memchr
Breakpoint 2 at 0x9000000001b0d60
(gdb) c
Continuing.

Thread 2 hit Breakpoint 2, 0x09000000001b0d60 in memchr () from /usr/lib/libc.a(shr_64.o)
(gdb) i register
r0             0x9000000001b0d60        648518346343124320
r1             0xfffffffffffc8d0        1152921504606832848
r2             0x9001000a008e8b8        648535941212334264
r3             0xa000000003669e0        720575940382845408
r4             0x64     100
r5             0x0      0
r6             0x9001000a04ee730        648535941216921392
r7             0x0      0
...
(gdb) x/s $r3
0xa000000003669e0:      "abcdef"

So:
 - the string is passed as r3.
 - r4 contains "d" = 0x64=100
 - but the size 7 is missing

Anyway, it seems that ffi does not pass the pointer, but values. However, the length 7 is missing. Not in r5, and nowhere in the other registers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 09:56:19 2020
From: report at bugs.python.org (n-io)
Date: Fri, 24 Jul 2020 13:56:19 +0000
Subject: [issue41382] print() unpredictable behaviour
Message-ID: <1595598979.89.0.398594885815.issue41382@roundup.psfhosted.org>


New submission from n-io <stawi78 at hotmail.com>:

There seems to be a behavioural issue with the print() function. Using python3.8 and the following line:

>>> print("\t".join(['arith_int_512-cuda.sfeat', '__hipsyclkernel$wrapped_kernelname$MicroBenchArithmeticKernel_512_1', '578', '65', '5', '64', '4', '1025', '128', '1', '1', '512', '1']))

arith_int_512-cuda.sfeat    __hipsyclkernel$wrapped_kernelname$MicroBenchArithmeticKernel_512_1    578    65    5    64    4    1025    128    512    1

Notice the missing numbers between 128 and 512. If I do random modifications the either of the first two string, some of the missing numbers may appear. For instance:

>>> print("\t".join(['arith_int_512-cuda', '__hipsycl_kernel_$wrapped_kernel_name_$MicroBenchArithmeticKernel_512_1', '578', '65', '5', '64', '4', '1025', '128', '1', '1', '512', '1']))

arith_int_512-cuda	__hipsycl_kernel_$wrapped_kernel_name_$MicroBenchArithmeticKernel_512_1	578	65	5	64	4	1025	128	1	512	1

Notice that one of the two missing numbers has appeared. There appears nothing wrong with the value used to invoke print.

The error appears to be linked to joining on the "\t" character and does not appear to occur when joining on other whitespace characters such as " ".join(...) or "\n".join(...)

----------
components: IO
messages: 374176
nosy: n-io
priority: normal
severity: normal
status: open
title: print() unpredictable behaviour
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41382>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:00:37 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 24 Jul 2020 14:00:37 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595599237.44.0.831726871158.issue41350@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm a little surprised from Nick's original post that the behavior is triggered. After all, the code [already has a protection for a previously-closed zipfile](https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/zipfile.py#L1812-L1813) and that value is [unconditionally set during close](https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/zipfile.py#L1828). So how is it that Zipfile.__del__ is being called?

Jeffrey suggests that

> a copy of the zip_file object is getting created, probably by the Path constructor

And indeed, I can confirm the ZipFile [state is copied into a new object here](https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/zipfile.py#L2202). The FastLookup and CompleteDirs functionality is for performance optimizations.

> I created a simpler test case that exercises the buggy code.

Although the simpler test does trigger the error, I'd argue that the error is _expected_ in this case and that the zip file will be invalid because `self._write_end_record` will never get called.

I expected this example to more accurately capture the failure:

```
import io
import zipfile
buf = io.BytesIO()
zf = zipfile.ZipFile(buf, mode='w')
zp = zipfile.Path(zf)
with zp.joinpath('zile-a').open('w') as fp:
    fp.write(b'contents of file-a')
zf.close()
zp.root.close()
```

But it does not. I'll need to do more investigation.

One option here is for `Path` to document that any zipfile passed to it is no longer valid and enforce that fact by disabling the original object passed to it.

Another approach could be to try to use an adapter pattern to adapt the original ZipFile rather than clone it into a subclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:04:04 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 14:04:04 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595599444.09.0.92373891638.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

On Fedora/x86_64, in order to get the core, one must do:
  coredumpctl -o /tmp/core dump /usr/bin/python3.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:04:53 2020
From: report at bugs.python.org (Bernat Gabor)
Date: Fri, 24 Jul 2020 14:04:53 +0000
Subject: [issue41383] Provide a limit arguments for __repr__
Message-ID: <1595599493.43.0.939554432548.issue41383@roundup.psfhosted.org>


New submission from Bernat Gabor <gaborjbernat at gmail.com>:

Quoting Elizaveta Shashkova from EuroPython 2020 chat about how can we improve debug experience for users:

I would like to have a lazy repr evaluation for the objects! Sometimes users have many really large objects, and when debugger is trying to show them in Variables View (=show their string representation) it can takes a lot of time. We do some tricks, but they not always work. It would be really-really cool to have parameter in repr, which defines max number of symbols we want to evaluate during repr for this object.

What do people, would this optional str limit be a good thing? Does anyone has a better idea?

----------
components: Interpreter Core
messages: 374179
nosy: Bernat Gabor
priority: normal
severity: normal
status: open
title: Provide a limit arguments for __repr__
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41383>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:06:21 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 14:06:21 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595599581.04.0.111859371022.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

On Fedora/PPC64LE, where it is OK, the same debug with gdb gives:

(gdb) where
#0  0x00007ffff7df03b0 in __memchr_power8 () from /lib64/libc.so.6
#1  0x00007fffea167680 in ?? () from /lib64/libffi.so.6
#2  0x00007fffea166284 in ffi_call () from /lib64/libffi.so.6
#3  0x00007fffea1a7fdc in _ctypes_callproc () from /usr/lib64/python3.8/lib-dynload/_ctypes.cpython-38-ppc64le-linux-gnu.so
..........
(gdb) i register
r0             0x7fffea167614      140737120728596
r1             0x7fffffffc490      140737488340112
r2             0x7fffea187f00      140737120861952
r3             0x7fffea33a140      140737122640192
r4             0x6464              25700
r5             0x7                 7
r6             0x0                 0
r7             0x7fffea33a147      140737122640199
r8             0x7fffea33a140      140737122640192

(gdb) x/s 0x7fffea33a140
0x7fffea33a140: "abcdef"

r3: string
r4 : 0x6464 : "d" ??
r5: 7 : length of the string !!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:06:37 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 24 Jul 2020 14:06:37 +0000
Subject: [issue41382] print() unpredictable behaviour
In-Reply-To: <1595598979.89.0.398594885815.issue41382@roundup.psfhosted.org>
Message-ID: <1595599597.54.0.422963772299.issue41382@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

On MacOS with Python 3.8.2 I get the correct results. Can you give more details about the platform and send the result of:


    >>> "\t".join(['arith_int_512-cuda.sfeat', '__hipsyclkernel$wrapped_kernelname$MicroBenchArithmeticKernel_512_1', '578', '65', '5', '64', '4', '1025', '128', '1', '1', '512', '1'])

?


Could you also try `echo 'arith_int_512-cuda.sfeat\t__hipsyclkernel$wrapped_kernelname$MicroBenchArithmeticKernel_512_1\t578\t65\t5\t64\t4\t1025\t128\t1\t1\t512\t1'` in shell? Maybe your terminal emulator behaves weirdly.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41382>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:10:04 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 24 Jul 2020 14:10:04 +0000
Subject: [issue41383] Provide a limit arguments for __repr__
In-Reply-To: <1595599493.43.0.939554432548.issue41383@roundup.psfhosted.org>
Message-ID: <1595599804.92.0.873186205562.issue41383@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Bernat, have you looked into reprlib.repr()? It's an alternative implementation of repr() made for cases like this.

You may be interested in this PR too: https://github.com/python/cpython/pull/20925

Alternatively, I think pprint.pformat() may be useful for your purpose too.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41383>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:10:45 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 14:10:45 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595599845.79.0.181876256244.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

On AIX in 32bit, we have:

Thread 2 hit Breakpoint 2, 0xd01407e0 in memchr () from /usr/lib/libc.a(shr.o)
(gdb) where
#0  0xd01407e0 in memchr () from /usr/lib/libc.a(shr.o)
#1  0xd438f480 in ffi_call_AIX () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2  0xd438effc in ffi_call () from /opt/freeware/lib/libffi.a(libffi.so.6)
....
(gdb) i register
r0             0xd01407e0       3490973664
r1             0x2ff20f80       804392832
r2             0xf07a3cc0       4034542784
r3             0xb024c558       2955199832
r4             0x64     100
r5             0x7      7
r6             0x0      0
...

(gdb) x/s 0xb024c558
0xb024c558:     "abcdef"

r5 is OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:12:20 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jul 2020 14:12:20 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1595599940.52.0.223707539004.issue32528@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20747
pull_request: https://github.com/python/cpython/pull/21606

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:16:36 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 14:16:36 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595600195.99.0.833279158522.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

AIX: difference between 32bit and 64bit.

After the second print, the stack is:

32bit:
#0  0xd01407e0 in memchr () from /usr/lib/libc.a(shr.o)
#1  0xd438f480 in ffi_call_AIX () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2  0xd438effc in ffi_call () from /opt/freeware/lib/libffi.a(libffi.so.6)
#3  0xd14979bc in ?? ()
#4  0xd148995c in ?? ()
#5  0xd20fd5d8 in _PyObject_MakeTpCall () from /opt/freeware/lib/libpython3.8.so

64bit:
#0  0x09000000001b0d60 in memchr () from /usr/lib/libc.a(shr_64.o)
#1  0x0900000001217f00 in ffi_closure_ASM () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2  0x0900000001217aac in ffi_prep_closure_loc () from /opt/freeware/lib/libffi.a(libffi.so.6)
#3  0x0900000000d30900 in ?? ()
#4  0x0900000000d22b6c in ?? ()
#5  0x0900000000ebbc18 in _PyObject_MakeTpCall () from /opt/freeware/lib64/libpython3.8.so

So, the execution does not run in the same ffi routines in 32bit and in 64bit. Bug ?

It should be interesting to do the same with Python3 and libffi built with -O0 -g maybe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:19:21 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jul 2020 14:19:21 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1595600361.01.0.557946821927.issue32528@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ba07d4a0c30b4d817b4c31a052388a68cc17bc3b by Miss Islington (bot) in branch '3.9':
bpo-32528: Document the change in inheritance of asyncio.CancelledError (GH-21474)
https://github.com/python/cpython/commit/ba07d4a0c30b4d817b4c31a052388a68cc17bc3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:38:38 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jul 2020 14:38:38 +0000
Subject: [issue41371] test_zoneinfo fails
In-Reply-To: <1595449050.37.0.742582022147.issue41371@roundup.psfhosted.org>
Message-ID: <1595601518.08.0.673348557651.issue41371@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I got this error as well. Since lzma is needed to decode the test data the ImportError can be captured to skip the test in setUpModule [0] like other test module setup with similar approach for required cases. I am adding easy tag. Feel free to retriage this if the test data need to be encoded in a different format for the test to support platforms that don't have lzma.

try:
   import lzma
except ImportError:
   raise unittest.skipTest("lzma is needed")


[0] https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/test/test_zoneinfo/test_zoneinfo.py#L43

----------
keywords: +easy, newcomer friendly
nosy: +xtreak
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41371>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:39:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jul 2020 14:39:01 +0000
Subject: [issue41371] test_zoneinfo fails when lzma module is unavailable
In-Reply-To: <1595449050.37.0.742582022147.issue41371@roundup.psfhosted.org>
Message-ID: <1595601541.34.0.830317103125.issue41371@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
title: test_zoneinfo fails -> test_zoneinfo fails when lzma module is unavailable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41371>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:41:04 2020
From: report at bugs.python.org (n-io)
Date: Fri, 24 Jul 2020 14:41:04 +0000
Subject: [issue41382] print() unpredictable behaviour
In-Reply-To: <1595598979.89.0.398594885815.issue41382@roundup.psfhosted.org>
Message-ID: <1595601664.76.0.312754703366.issue41382@roundup.psfhosted.org>


n-io <stawi78 at hotmail.com> added the comment:

The first call you requested (as hinted before, this looks fine to me):
$ python3.8
Python 3.8.3 (default, May 14 2020, 22:09:32) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> "\t".join(['arith_int_512-cuda.sfeat', '__hipsyclkernel$wrapped_kernelname$MicroBenchArithmeticKernel_512_1', '578', '65', '5', '64', '4', '1025', '128', '1', '1', '512', '1'])
'arith_int_512-cuda.sfeat\t__hipsyclkernel$wrapped_kernelname$MicroBenchArithmeticKernel_512_1\t578\t65\t5\t64\t4\t1025\t128\t1\t1\t512\t1'


I can reproduce the issue on both:

Python 3.8.3 (default, May 14 2020, 22:09:32) 
[GCC 5.4.0 20160609] on linux

Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 26 2018, 19:50:54) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin


The second call you requested `echo 'arith_int_512-....'` will say 'command not found: arith_.....' in bash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41382>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:48:31 2020
From: report at bugs.python.org (Akuli)
Date: Fri, 24 Jul 2020 14:48:31 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
Message-ID: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>


New submission from Akuli <akuviljanen17 at gmail.com>:

from Lib:tkinter/__init__.py:

    raise TclError('unknown option -'+kwargs.keys()[0])

This is no longer valid in Python 3.

----------
components: Tkinter
messages: 374188
nosy: Akuli
priority: normal
pull_requests: 20748
severity: normal
status: open
title: tkinter raises TypeError when it's supposed to raise TclError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:50:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jul 2020 14:50:50 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
Message-ID: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

https://dev.azure.com/Python/cpython/_build/results?buildId=66688&view=logs&j=0fcf9c9b-89fc-526f-8708-363e467e119e&t=fa5ef4ee-3911-591e-4444-19482ab189b7&l=740

======================================================================
ERROR: test_executable_without_cwd (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\1\b\layout-appx-win32\lib\test\test_subprocess.py", line 470, in test_executable_without_cwd
    self._assert_cwd(os.getcwd(), "somethingyoudonthave",
  File "D:\a\1\b\layout-appx-win32\lib\test\test_subprocess.py", line 388, in _assert_cwd
    normcase(p.stdout.read().decode("utf-8")))
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe6 in position 40: unexpected end of data

https://dev.azure.com/Python/cpython/_pipeline/analytics/stageawareoutcome?definitionId=4 for 30 days.

99.16% of pipeline failures are due to failures in task - appx Tests

----------
components: Tests, Windows
messages: 374189
nosy: paul.moore, steve.dower, tim.golden, xtreak, zach.ware
priority: normal
severity: normal
status: open
title: test_executable_without_cwd fails on appx test run in Azure pipelines
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:53:07 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jul 2020 14:53:07 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595602387.18.0.000244057347041.issue41384@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gpolo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:55:17 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Jul 2020 14:55:17 +0000
Subject: [issue41382] print() unpredictable behaviour
In-Reply-To: <1595598979.89.0.398594885815.issue41382@roundup.psfhosted.org>
Message-ID: <1595602517.41.0.0348278523314.issue41382@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

It would help if you could pare this down to a simpler example, hopefully removing the '$'.

For example, does the problem still occur if you '$'s? What if you make all of the non-numeric strings 1 character long? What if you delete the non-numeric strings?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41382>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:04:16 2020
From: report at bugs.python.org (Tony Reix)
Date: Fri, 24 Jul 2020 15:04:16 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595603056.13.0.189343361383.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

# pwd
/opt/freeware/src/packages/BUILD/libffi-3.2.1

# grep -R ffi_closure_ASM *
powerpc-ibm-aix7.2.0.0/.libs/libffi.exp:         ffi_closure_ASM
powerpc-ibm-aix7.2.0.0/include/ffitarget.h:    void * code_pointer;       /* Pointer to ffi_closure_ASM */
src/powerpc/aix_closure.S:                .globl ffi_closure_ASM
src/powerpc/darwin_closure.S:            .globl _ffi_closure_ASM
src/powerpc/ffi_darwin.c:                 extern void ffi_closure_ASM (void);
                                          *((unsigned long *)&tramp[2]) = (unsigned long) ffi_closure_ASM; /* function  */
src/powerpc/ffitarget.h:                  void * code_pointer;  /* Pointer to ffi_closure_ASM */

# grep -R ffi_call_AIX *
powerpc-ibm-aix7.2.0.0/.libs/libffi.exp:  ffi_call_AIX
src/powerpc/aix.S:                        .globl ffi_call_AIX
src/powerpc/ffi_darwin.c:                 extern void ffi_call_AIX(extended_cif *, long, unsigned, unsigned *,

In 64bit, I see that: ffi_darwin.c  is compiled and used for building libffi.so.6 .
Same in 32bit.

The code of file src/powerpc/ffi_darwin.c seems to be able to handle both FFI_AIX and FFI_DARWIN , dynamically based on cif->abi .

The code looks like VERY complex!

The hypothesis is that the 64bit code has a bug vs the 32bit version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:03:58 2020
From: report at bugs.python.org (Bernat Gabor)
Date: Fri, 24 Jul 2020 15:03:58 +0000
Subject: [issue41383] Provide a limit arguments for __repr__
In-Reply-To: <1595599493.43.0.939554432548.issue41383@roundup.psfhosted.org>
Message-ID: <1595603038.84.0.153269919879.issue41383@roundup.psfhosted.org>


Bernat Gabor <gaborjbernat at gmail.com> added the comment:

Thanks R?mi, did not know about it. Played around with it, and is not entirely what we'd need here. That class still generates the long string repr, just truncates it afterwards. That is unless teh Repr implements custom formatting for the types, however the Repr would be the IDEs code, and that doesn't understand enough the user code to be able to tell what's a good short representation for it. This was the idea with adding it as a parameter to the repr function, that the user can customize/override the outcome depenending how many characters it has left to use up for repr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41383>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:06:23 2020
From: report at bugs.python.org (n-io)
Date: Fri, 24 Jul 2020 15:06:23 +0000
Subject: [issue41382] print() unpredictable behaviour
In-Reply-To: <1595598979.89.0.398594885815.issue41382@roundup.psfhosted.org>
Message-ID: <1595603183.06.0.478957954498.issue41382@roundup.psfhosted.org>


n-io <stawi78 at hotmail.com> added the comment:

Redirecting the stdout of the command to a file (script.py > out) shows the output being produced correctly. The bug seems therefore unrelated to python, my apologies. Thanks though!

FYI, "$cat out" will reproduce the bug, while "$vi out" will show the correct output as expected. Your intuition seemed correct, thanks.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41382>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:54:41 2020
From: report at bugs.python.org (Nico)
Date: Fri, 24 Jul 2020 15:54:41 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
Message-ID: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>


New submission from Nico <nicofroehlich at icloud.com>:

Following problem occurred.

A C style program can have negative return codes. However this is not correctly implemented in the Windows API. Therefore it is being returned as unsigned long by the API hence it leads to ambiguity while comparing return codes.

For reference regarding this topic see:
https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?redirectedfrom=MSDN&view=vs-2019
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getexitcodeprocess

I suggest a

----------
components: Windows
messages: 374194
nosy: MrTroble, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Popen.wait does not account for negative return codes
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:58:07 2020
From: report at bugs.python.org (Nico)
Date: Fri, 24 Jul 2020 15:58:07 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595606287.19.0.058081024481.issue41386@roundup.psfhosted.org>


Nico <nicofroehlich at icloud.com> added the comment:

I suggest implementing a singed conversation into _wait

----------
keywords: +patch
message_count: 1.0 -> 2.0
pull_requests: +20749
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21607

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 12:22:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2020 16:22:41 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
In-Reply-To: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>
Message-ID: <1595607761.12.0.218020098598.issue41385@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 5.0 -> 6.0
pull_requests: +20750
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21608

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Fri Jul 24 12:30:21 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 24 Jul 2020 16:30:21 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595608221.79.0.469491246322.issue41350@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This routine will repro the issue without relying on garbage collection to trigger the error:

```
import io
import zipfile
buf = io.BytesIO()
zf = zipfile.ZipFile(buf, mode='w')
zp = zipfile.Path(zf)
with zp.joinpath('zile-a').open('w') as fp:
    fp.write('contents of file-a')
zf.close()
buf.close()
zp.root.close()
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 12:35:57 2020
From: report at bugs.python.org (Antonio Gutierrez)
Date: Fri, 24 Jul 2020 16:35:57 +0000
Subject: [issue41387] Wrong example, need scpae \"
Message-ID: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>


New submission from Antonio Gutierrez <antdcs at gmail.com>:

In the main documentation, the example:

#!/usr/bin/env python3

import smtplib

from email.message import EmailMessage
from email.headerregistry import Address
from email.utils import make_msgid

# Create the base text message.
msg = EmailMessage()
msg['Subject'] = "Ayons asperges pour le d?jeuner"
msg['From'] = Address("Pep? Le Pew", "pepe", "example.com")
msg['To'] = (Address("Penelope Pussycat", "penelope", "example.com"),
             Address("Fabrette Pussycat", "fabrette", "example.com"))
msg.set_content("""\
Salut!

Cela ressemble ? un excellent recipie[1] d?jeuner.

[1] http://www.yummly.com/recipe/Roasted-Asparagus-Epicurious-203718

--Pep?
""")

# Add the html version.  This converts the message into a multipart/alternative
# container, with the original text message as the first part and the new html
# message as the second part.
asparagus_cid = make_msgid()
msg.add_alternative("""\
<html>
  <head></head>
  <body>
    <p>Salut!</p>
    <p>Cela ressemble ? un excellent
        <a href="http://www.yummly.com/recipe/Roasted-Asparagus-Epicurious-203718">
            recipie
        </a> d?jeuner.
    </p>
    <img src="cid:{asparagus_cid}" />
  </body>
</html>
""".format(asparagus_cid=asparagus_cid[1:-1]), subtype='html')
# note that we needed to peel the <> off the msgid for use in the html.

# Now add the related image to the html part.
with open("roasted-asparagus.jpg", 'rb') as img:
    msg.get_payload()[1].add_related(img.read(), 'image', 'jpeg',
                                     cid=asparagus_cid)

# Make a local copy of what we are going to send.
with open('outgoing.msg', 'wb') as f:
    f.write(bytes(msg))

# Send the message via local SMTP server.
with smtplib.SMTP('localhost') as s:
    s.send_message(msg)



in the line <img src="cid:{asparagus_cid}" /> the " has to be escape, <img src=\"cid:{asparagus_cid}\" /> , otherwise it wont read the image.

----------
messages: 374197
nosy: Antonio Gutierrez
priority: normal
severity: normal
status: open
title: Wrong example, need scpae \"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 12:36:52 2020
From: report at bugs.python.org (Antonio Gutierrez)
Date: Fri, 24 Jul 2020 16:36:52 +0000
Subject: [issue41387] Wrong example, need scpae \"
In-Reply-To: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>
Message-ID: <1595608612.37.0.183496214825.issue41387@roundup.psfhosted.org>


Change by Antonio Gutierrez <antdcs at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 12:48:19 2020
From: report at bugs.python.org (Angel Siblani)
Date: Fri, 24 Jul 2020 16:48:19 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595609299.07.0.60497748575.issue41350@roundup.psfhosted.org>


Change by Angel Siblani <angelsiblany at gmail.com>:


----------
components: +Demos and Tools, XML, email -Library (Lib)
nosy: +angelsb, barry, r.david.murray
type: behavior -> resource usage
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Fri Jul 24 13:23:47 2020
From: report at bugs.python.org (Nico)
Date: Fri, 24 Jul 2020 17:23:47 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595611427.24.0.871973530073.issue41386@roundup.psfhosted.org>


Change by Nico <nicofroehlich at icloud.com>:


----------
components: +Library (Lib) -Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:05:46 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 24 Jul 2020 18:05:46 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>
Message-ID: <1595613946.8.0.468424193751.issue41387@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +barry, maxking, r.david.murray
title: Wrong example, need scpae \" -> Escape needed in the email documentation example

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:24:34 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Jul 2020 18:24:34 +0000
Subject: [issue41328] Hudson CI is not available anymore
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595615074.46.0.809138230196.issue41328@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Why not add Travis-CI and AppVeyor?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:26:41 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Jul 2020 18:26:41 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595615201.06.0.806868379172.issue41340@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Either remove it or close this issue as won?t fix.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:28:51 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Jul 2020 18:28:51 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595245426.33.0.812684814237.issue41345@roundup.psfhosted.org>
Message-ID: <1595615331.1.0.503430555524.issue41345@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This surely is some application corner case. Closing.

----------
nosy: +gvanrossum
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:32:14 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Jul 2020 18:32:14 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
In-Reply-To: <1595351360.26.0.0463175809492.issue41362@roundup.psfhosted.org>
Message-ID: <1595615534.03.0.226195740622.issue41362@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Is this really worth our attention? In 3.10 this will be irrelevant.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:54:45 2020
From: report at bugs.python.org (Anand Tripathi)
Date: Fri, 24 Jul 2020 09:54:45 +0000
Subject: [issue41381] Google chat handler in Logging module
In-Reply-To: <1595584203.13.0.479309356475.issue41381@roundup.psfhosted.org>
Message-ID: <CAPL-qY=Z3C5wTwWMd-3B0P0hoMnk_DWTkOWd6x0LCx-Pp6NK6g@mail.gmail.com>


Anand Tripathi <anand.tripathi507 at gmail.com> added the comment:

Yeah, it will be as same as the SMTP Handler. But yeah creating a library
wrapper around the logging package is also a good idea.
[image: image.png]

Thanks for the support.

Best,
Anand Tripathi

On Fri, Jul 24, 2020 at 3:20 PM R?mi Lapeyre <report at bugs.python.org> wrote:

>
> R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:
>
> Hi Anand, this is very specific to one product and I don't think the core
> team will take the burden to maintain to as it may be too specific. You
> could create a package and publish it on Pypi so others can use it thought.
>
> ----------
> components: +Library (Lib)
> nosy: +remi.lapeyre
> versions: +Python 3.10
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41381>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file49335/image.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 97784 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20200724/4bbc2d1f/attachment-0001.png>

From report at bugs.python.org  Fri Jul 24 14:35:45 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Jul 2020 18:35:45 +0000
Subject: [issue41377] memoryview of str (unicode)
In-Reply-To: <1595537187.85.0.858771420995.issue41377@roundup.psfhosted.org>
Message-ID: <1595615745.17.0.47939305828.issue41377@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We should not do this, it would expose internals that we need to keep private. The right approach would be to keep things as bytes.

----------
nosy: +gvanrossum
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41377>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:03:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Jul 2020 19:03:56 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595617436.52.0.74538759361.issue41380@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

There already is a decent set of examples. I think a Snake game is a worthy addition.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:05:53 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jul 2020 19:05:53 +0000
Subject: [issue41381] Google chat handler in Logging module
In-Reply-To: <1595584091.55.0.744768850804.issue41381@roundup.psfhosted.org>
Message-ID: <1595617553.31.0.0555072217338.issue41381@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

The difference is that SMTP is a universal, documented, vendor-independent Internet standard.  Google chat products are specific to one company, pose a maintenance issue (stable Python branches could not accept big changes if the API changes), and risk becoming obsolete (google released ten text and/or video chat systems, renamed them, merged them, removed them).  So this idea is not adequate for the standard library perfect for a package on PyPI!

----------
nosy: +eric.araujo
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:10:41 2020
From: report at bugs.python.org (Alexey Burdin)
Date: Fri, 24 Jul 2020 19:10:41 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
Message-ID: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>


New submission from Alexey Burdin <longsillyusernamealreadytaken8 at gmail.com>:

```
answers_field_order=sorted(
    set(j for i in data['items'] for j in i),
    key=cmp_to_key(lambda x,y:(
        -1 if (x,y) in answer_order 
        else (0 if x==y else 1)))
        )
```
when the cursor is placed in line 5 col 31 (between `)` and `))` ) hitting Ctrl-0 (Show surrounding parens) produces an error sound, though there's no error, the script works fine.

```
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.4 LTS
Release:	18.04
Codename:	bionic
$ uname -a
Linux odd-one 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ python3.8
Python 3.8.0 (default, Oct 28 2019, 16:14:01) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib
>>> importlib.util.find_spec('idlelib.pyshell')
ModuleSpec(name='idlelib.pyshell', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7f1ea8ee14c0>, origin='/usr/lib/python3.8/idlelib/pyshell.py')
>>> exit()
$ dpkg-query -S /usr/lib/python3.8/idlelib/pyshell.py
idle-python3.8: /usr/lib/python3.8/idlelib/pyshell.py
$ dpkg -l | grep idle-python3\.8
ii  idle-python3.8                             3.8.0-3~18.04                                    all          IDE for Python (v3.8) using Tkinter
```

----------
assignee: terry.reedy
components: IDLE
messages: 374205
nosy: Alexey Burdin, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE fails to detect corresponding opening parenthesis
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:25:08 2020
From: report at bugs.python.org (Lewis Ball)
Date: Fri, 24 Jul 2020 19:25:08 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>
Message-ID: <1595618708.92.0.470624135522.issue41387@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

So I have just tried it out and the example seems to work fine for me as it is (tested using 3.8.2).

Note that escaping the " in this case makes no difference to the string:
```
>>> """<img src="cid:{cid}" />""" == """<img src=\"cid:{cid}\" />"""
True
```

----------
nosy: +Lewis Ball

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:30:43 2020
From: report at bugs.python.org (Nico)
Date: Fri, 24 Jul 2020 19:30:43 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595619043.39.0.0542125108954.issue41386@roundup.psfhosted.org>


Change by Nico <nicofroehlich at icloud.com>:


----------
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:38:15 2020
From: report at bugs.python.org (Antonio Gutierrez)
Date: Fri, 24 Jul 2020 19:38:15 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595618708.92.0.470624135522.issue41387@roundup.psfhosted.org>
Message-ID: <CANaRyDiof_4=1yPChpsJKdVvjx-EvozdkUOHzC5GJ1y9esk5Kg@mail.gmail.com>


Antonio Gutierrez <antdcs at gmail.com> added the comment:

I forget to mention that I am receiving the mails with gmail, I don't know
if that is important or not. It shouldn't be different right, but for me it
is, if i don't use the escape the image is send and I can get it from the
attachment, but I am unable to see it in the html message. Maybe I am
doing something wrong.

El vie., 24 jul. 2020 a las 21:25, Lewis Ball (<report at bugs.python.org>)
escribi?:

>
> Lewis Ball <lrjball at gmail.com> added the comment:
>
> So I have just tried it out and the example seems to work fine for me as
> it is (tested using 3.8.2).
>
> Note that escaping the " in this case makes no difference to the string:
> ```
> >>> """<img src="cid:{cid}" />""" == """<img src=\"cid:{cid}\" />"""
> True
> ```
>
> ----------
> nosy: +Lewis Ball
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41387>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:35:40 2020
From: report at bugs.python.org (Aaron Black)
Date: Fri, 24 Jul 2020 19:35:40 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1595619340.88.0.184611951144.issue32958@roundup.psfhosted.org>


Aaron Black <aaron.black at jpl.nasa.gov> added the comment:

joseph.hackman

I don't think that the 63 character limit on a label is the problem specifically, merely it's application. 

The crux of my issue was that credentials passed with the url in a basic-authy fashion (as some services require) count against the label length. For example, this would trigger the error:

h = "https://ablack:very_long_api_key_0123456789012345678901234567890123456789012345678901234567890123 at www.example.com"

Since the first label would be treated as:
 "ablack:very_long_api_key_0123456789012345678901234567890123456789012345678901234567890123 at www"

My specific issue goes away if any text up to / including an "@" in the first label section is not included in the label validation. I don't know off hand if that information is supposed to be included per the label in the DNS spec though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32958>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:55:35 2020
From: report at bugs.python.org (Nico)
Date: Fri, 24 Jul 2020 19:55:35 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595620535.97.0.00505932730993.issue41386@roundup.psfhosted.org>


Nico <nicofroehlich at icloud.com> added the comment:

I don't know if it should be a good idea to add a flag to turn off the negative conversation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:56:23 2020
From: report at bugs.python.org (Ian O'Shaughnessy)
Date: Fri, 24 Jul 2020 19:56:23 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
Message-ID: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>


New submission from Ian O'Shaughnessy <ian_osh at apple.com>:

Using a script that has two classes A and B which contain a circular reference variable, it is possible to cause a memory leak that is not captured by default gc collection. Only by running gc.collect() manually do the circular references get collected.

Attached is a sample script that replicates the issue.

Output starts:

Ram used: 152.17 MB - A: Active(125) / Total(2485) - B: Active(124) / Total(2484)
Ram used: 148.17 MB - A: Active(121) / Total(12375) - B: Active(120) / Total(12374)
Ram used: 65.88 MB - A: Active(23) / Total(22190) - B: Active(22) / Total(22189)
Ram used: 77.92 MB - A: Active(35) / Total(31935) - B: Active(34) / Total(31934)

After 1,000,000 cycles 1GB of ram is being consumed:

Ram used: 1049.68 MB - A: Active(1019) / Total(975133) - B: Active(1018) / Total(975132)
Ram used: 1037.64 MB - A: Active(1007) / Total(984859) - B: Active(1006) / Total(984858)
Ram used: 952.34 MB - A: Active(922) / Total(994727) - B: Active(921) / Total(994726)
Ram used: 970.41 MB - A: Active(940) / Total(1000000) - B: Active(940) / Total(1000000)

----------
files: gc.bug.py
messages: 374210
nosy: ian_osh
priority: normal
severity: normal
status: open
title: Garbage Collector Ignoring Some (Not All) Circular References of Identical Type
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file49337/gc.bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:04:45 2020
From: report at bugs.python.org (Antonio Gutierrez)
Date: Fri, 24 Jul 2020 20:04:45 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <CANaRyDiof_4=1yPChpsJKdVvjx-EvozdkUOHzC5GJ1y9esk5Kg@mail.gmail.com>
Message-ID: <CANaRyDiLShVirh_Z54-Nnwm3eznN19jR-J6aTomqf6xKhzQVXg@mail.gmail.com>


Antonio Gutierrez <antdcs at gmail.com> added the comment:

OK, first I am sorry , I did try again when I read your message( because it
has all the sense), and yes it works, probably I corrected something else
that made it work, i don't know. I'll try to make better reports in the
future.

El vie., 24 jul. 2020 a las 21:38, Antonio Gutierrez (<
report at bugs.python.org>) escribi?:

>
> Antonio Gutierrez <antdcs at gmail.com> added the comment:
>
> I forget to mention that I am receiving the mails with gmail, I don't know
> if that is important or not. It shouldn't be different right, but for me it
> is, if i don't use the escape the image is send and I can get it from the
> attachment, but I am unable to see it in the html message. Maybe I am
> doing something wrong.
>
> El vie., 24 jul. 2020 a las 21:25, Lewis Ball (<report at bugs.python.org>)
> escribi?:
>
> >
> > Lewis Ball <lrjball at gmail.com> added the comment:
> >
> > So I have just tried it out and the example seems to work fine for me as
> > it is (tested using 3.8.2).
> >
> > Note that escaping the " in this case makes no difference to the string:
> > ```
> > >>> """<img src="cid:{cid}" />""" == """<img src=\"cid:{cid}\" />"""
> > True
> > ```
> >
> > ----------
> > nosy: +Lewis Ball
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue41387>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41387>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:11:31 2020
From: report at bugs.python.org (Nico)
Date: Fri, 24 Jul 2020 20:11:31 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595621491.24.0.761838524422.issue41386@roundup.psfhosted.org>


Nico <nicofroehlich at icloud.com> added the comment:

We apparently need a flag to ensure compatibility with the windows return codes

======================================================================
FAIL: test_disable_windows_exc_handler (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_faulthandler.py", line 825, in test_disable_windows_exc_handler
    self.assertEqual(exitcode, 0xC0000005)
AssertionError: -1073741819 != 3221225477

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:45:54 2020
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jul 2020 20:45:54 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>
Message-ID: <1595623554.87.0.937619252376.issue41387@roundup.psfhosted.org>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:48:32 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 24 Jul 2020 20:48:32 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595623712.38.0.650342956328.issue41389@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I see no evidence of a bug here. To the contrary, the output proves that __del__ methods are getting called all along. And if garbage weren't being collected, after allocating a million objects each with its own megabyte string object, memory use at the end would be a terabyte, not a comparatively measly ;-) gigabyte

Note that Python's cyclic gc is NOT asynchronous. It only runs when you call it directly, or when an internal count of allocations exceeds an internal count of deallocations. When your loop ends, your output shows that 940 A and B objects remain to be collected, spread across some number of the gc's "generations". That's where your gigabyte lives (about a thousand A objects each with its own megabyte of string data). It will remain in use until gc is forced to run again. But 99.9% of the A objects have already been collected.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:52:20 2020
From: report at bugs.python.org (Ian O'Shaughnessy)
Date: Fri, 24 Jul 2020 20:52:20 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595623940.7.0.274065401196.issue41389@roundup.psfhosted.org>


Ian O'Shaughnessy <ian_osh at apple.com> added the comment:

For a long running process (greatly exceeding a million iterations) the uncollected garbage will become too large for the system (many gigabytes). A manual execution of the gc would be required.

That seems flawed given that Python is a garbage collected language, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Fri Jul 24 17:13:11 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 24 Jul 2020 21:13:11 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595625191.6.0.662546316914.issue41389@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

What makes you think that? Your own output shows that the number of "Active" objects does NOT monotonically increase across output lines. It goes up sometimes, and down sometimes.  Whether it goes up or down is entirely due to accidents of when your monitoring thread happens to wake up during the lifetime of the program's gc history.

I boosted the loop count to 10 million on my box just now. It had no significant effect on peak memory use. At the end:

>>> A.COUNT, A.TOTAL, B.COUNT, B.TOTAL
(298, 10000000, 298, 10000000)
>>> gc.collect()
1188
>>> A.COUNT, A.TOTAL, B.COUNT, B.TOTAL
(1, 10000000, 1, 10000000)

There is no leak. An A and B object survive collect() because the last A object created remains bound to the variable `a` used in the loop (so is still reachable).

So I thank you for creating a nice test program, but I'm closing this since it doesn't demonstrate a real problem.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Fri Jul 24 17:16:09 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 24 Jul 2020 21:16:09 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595625369.19.0.701305828925.issue38628@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Fri Jul 24 17:59:45 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jul 2020 21:59:45 +0000
Subject: [issue41381] Google chat handler in Logging module
In-Reply-To: <1595584091.55.0.744768850804.issue41381@roundup.psfhosted.org>
Message-ID: <1595627985.95.0.451195292693.issue41381@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Agreed that a library on PyPI is the appropriate way to resolve this.

----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Fri Jul 24 19:10:00 2020
From: report at bugs.python.org (Lewis Ball)
Date: Fri, 24 Jul 2020 23:10:00 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>
Message-ID: <1595632200.57.0.262995969381.issue41387@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

Okay no worries, glad it is all sorted now :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Fri Jul 24 19:58:19 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 24 Jul 2020 23:58:19 +0000
Subject: [issue22431] Change format of test runner output
In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za>
Message-ID: <1595635099.55.0.834731501683.issue22431@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 8.0 -> 9.0
pull_requests: +20751
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22431>
_______________________________________

From report at bugs.python.org  Fri Jul 24 20:37:10 2020
From: report at bugs.python.org (Lewis Ball)
Date: Sat, 25 Jul 2020 00:37:10 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595637430.03.0.832698692005.issue41388@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

A minimal example of the same issue seems to be:
```
(1 if x
 else 0)
```
In this case the parentheses matching also fails. It only ever seems to fail when `else` is the first word on a newline inside brackets, and adding the line break elsewhere in the above statement will not cause the matching to fail. 

I imagine it stops looking for the matching parentheses when it gets to the `else` statement, as an `else` when part of an `if/else` cannot be inside parentheses. Obviously the exception to this is the ternary operator.

Bizarrely, it only seems to fail the first time it encounters this issue. Any subsequent code with the same pattern seems to be matched fine. So in the following example, the second brackets get matched without an issue:

```
(1 if x
 else 0)

(1 if x
 else 0)
```

Hopefully someone more familiar with the source code can shed some light on this!

----------
nosy: +Lewis Ball

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Fri Jul 24 20:46:58 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 25 Jul 2020 00:46:58 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595638018.44.0.421987577907.issue41386@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In the Windows API, errors and exit status codes are all unsigned 32-bit integers. See SetLastError, GetLastError, ExitThread, ExitProcess, GetExitCodeThread, and GetExitCodeProcess. Even signed NTSTATUS and HRESULT values are commonly displayed as non-negative values, and, as exit status values, they're usually matched as unsigned integers. 

I think, if anything, it should suffice to document the range of `Popen.returncode` in Windows as a 32-bit unsigned integer.

---

Even POSIX systems in many cases have no use for the signed exit status from C exit(). The POSIX wait() and waitpid() system calls only provide the lower byte (i.e. masked by 0xFF) of the exit status. The subprocess module takes advantage of this on POSIX systems in order to reserve negative return codes to indicate termination by a signal. 

The newer waitid() system call should be able to return the signed 32-bit exit status. I think that's implemented on BSD and macOS, but waitid() in Linux 5.4 appears to only return the masked 8-bit status. For example:

    >>> p = subprocess.Popen(['python', '-c', 'import os; os._exit(-1)'])
    >>> os.waitid(os.P_PID, p.pid, os.WEXITED).si_status
    255

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:19:38 2020
From: report at bugs.python.org (Hugo Delgado)
Date: Sat, 25 Jul 2020 02:19:38 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1595643578.64.0.154302990744.issue24955@roundup.psfhosted.org>


Hugo Delgado <live2trance at gmail.com> added the comment:

I've bumped into this and won't mind working on it, is it ok for me to try to finish it?

----------
nosy: +Hugo Delgado

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:26:41 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 25 Jul 2020 02:26:41 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1595644001.97.0.408968649209.issue24955@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hugo, please go ahead and a test for this patch.

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:43:30 2020
From: report at bugs.python.org (hudelgado)
Date: Sat, 25 Jul 2020 02:43:30 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1595645010.59.0.403225064255.issue24955@roundup.psfhosted.org>


hudelgado <live2trance at gmail.com> added the comment:

Ok, I'm thinking in also replace the os.popen calls with subprocess.Popen to keep consistency with existing tests.
Do you think it's a good approach? Or should be better to just add some tests around the current implementation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:39:19 2020
From: report at bugs.python.org (Tomasz Kloczko)
Date: Sat, 25 Jul 2020 02:39:19 +0000
Subject: [issue41390] Errors and warnings on generate butecode files
Message-ID: <1595644759.87.0.69067267227.issue41390@roundup.psfhosted.org>


New submission from Tomasz Kloczko <kloczko.tomasz at gmail.com>:

Python 3.9b5
In my rpm package during install I'm generating all .py{c,o} files.
During that process I found that there are emoted several errors and errors. Looks like still some old python 2,x syntax bits are still around

Full output of that part of install process:

+ LD_LIBRARY_PATH=/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib-dynload/:/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64
+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9
+ /home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/bin/python -s -B -m compileall -f -j48 -o 0 -o 1 -o 2 -s /home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64 -p / /home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9 --hardlink-dupes
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/__future__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/__phello__.foo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_aix_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_bootlocale.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_bootsubprocess.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_collections_abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_compat_pickle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_compression.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_osx_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_markupbase.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_py_abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_pydecimal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_pyio.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_sitebuiltins.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_strptime.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_sysconfigdata__linux_x86_64-linux-gnu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_sysconfigdata_d_linux_x86_64-linux-gnu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_threading_local.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/_weakrefset.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/aifc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/antigravity.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/argparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ast.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asynchat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/base_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/base_tasks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/base_subprocess.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/constants.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/base_futures.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/coroutines.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/exceptions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/futures.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/format_helpers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/locks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/log.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/protocols.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/proactor_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/queues.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/runners.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/sslproto.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/selector_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/staggered.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/streams.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/subprocess.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/tasks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/threads.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/transports.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/trsock.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/unix_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/windows_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncore.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/base64.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/asyncio/windows_utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/bdb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/binhex.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/bz2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/cProfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/bisect.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/calendar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/cgi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/cgitb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/chunk.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/cmd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/code.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/codecs.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/collections'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/codeop.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/collections/abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/collections/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/colorsys.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/compileall.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent/futures'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent/futures/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent/futures/_base.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent/futures/process.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/concurrent/futures/thread.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/python-config.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/python-config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/configparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/contextlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/contextvars.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/copyreg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/copy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/crypt.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/csv.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/_aix.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/macholib'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/_endian.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/macholib/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/macholib/dyld.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/macholib/dylib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/macholib/framework.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_anon.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_array_in_pointer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_arrays.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_as_parameter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_bitfields.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_buffers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_bytes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_byteswap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_callbacks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_cast.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_cfuncs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_checkretval.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_delattr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_errno.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_find.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_frombuffer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_funcptr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_functions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_incomplete.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_init.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_internals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_keeprefs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_libc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_loading.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_macholib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_memfunctions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_numbers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_objects.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_pep3118.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_parameters.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_pickling.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_pointers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_prototypes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_python_api.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_random_things.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_refcounts.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_repr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_returnfuncptrs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_simplesubclasses.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_sizes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_slicing.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_stringptr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_strings.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_struct_fields.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_structures.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_unaligned_structures.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/curses'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_unicode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_values.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_varsize_struct.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_win32.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/test/test_wintypes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ctypes/wintypes.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dbm'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/curses/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/curses/ascii.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/curses/has_key.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/curses/panel.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/curses/textpad.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dataclasses.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/datetime.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dbm/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dbm/dumb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dbm/gnu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/decimal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/difflib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dbm/ndbm.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/dis.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/_msvccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/archive_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/bcppcompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/ccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/cmd.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/bdist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/bdist_dumb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/bdist_msi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/bdist_rpm.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/bdist_wininst.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/build.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/build_clib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/build_ext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/build_py.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/build_scripts.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/check.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/clean.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/install.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/install_data.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/install_egg_info.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/install_headers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/install_lib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/install_scripts.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/register.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/sdist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/command/upload.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/core.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/cygwinccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/debug.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/dep_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/dir_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/dist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/errors.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/extension.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/fancy_getopt.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/file_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/filelist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/log.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/msvc9compiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/msvccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/spawn.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/sysconfig.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_archive_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_bdist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_bdist_dumb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_bdist_msi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_bdist_rpm.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_bdist_wininst.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_build.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_build_clib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_build_ext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_build_py.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_build_scripts.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_check.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_cmd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_clean.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_config_cmd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_cygwinccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_core.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_dep_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_dir_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_extension.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_dist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_file_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_filelist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_install.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_install_data.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_install_headers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_install_lib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_install_scripts.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_log.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_msvc9compiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_msvccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_register.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_sdist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_sysconfig.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_spawn.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_text_file.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_unixccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_upload.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_version.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/tests/test_versionpredicate.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/text_file.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/unixccompiler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/version.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/versionpredicate.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/doctest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/distutils/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/_encoded_words.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/_header_value_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/_parseaddr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/_policybase.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/base64mime.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/charset.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/contentmanager.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/encoders.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/errors.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/feedparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/generator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/header.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/headerregistry.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/iterators.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/message.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/application.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/audio.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/base.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/image.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/message.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/multipart.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/nonmultipart.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/mime/text.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/policy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/quoprimime.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/email/utils.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/ascii.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/aliases.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/base64_codec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/big5.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/big5hkscs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/bz2_codec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/charmap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp037.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1006.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1026.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1125.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1140.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1250.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1251.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1252.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1253.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1254.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1255.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1256.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1258.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp273.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp437.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp1257.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp500.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp424.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp720.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp737.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp775.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp850.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp852.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp855.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp856.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp857.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp860.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp858.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp861.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp862.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp863.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp865.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp864.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp866.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp874.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp869.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp932.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp875.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp949.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/cp950.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/euc_jis_2004.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/euc_jisx0213.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/euc_jp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/euc_kr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/gb18030.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/gb2312.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/gbk.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/hex_codec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/hp_roman8.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/hz.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/idna.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_jp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_jp_1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_jp_2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_jp_2004.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_jp_3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_jp_ext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso2022_kr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_10.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_11.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_13.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_14.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_15.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_16.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_4.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_5.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_6.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_7.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_8.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/iso8859_9.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/johab.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/koi8_r.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/koi8_t.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/koi8_u.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/kz1048.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/latin_1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_croatian.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_arabic.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_cyrillic.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_farsi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_greek.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_iceland.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_romanian.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_roman.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_turkish.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mac_latin2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/mbcs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/oem.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/palmos.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/ptcp154.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/punycode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/quopri_codec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/raw_unicode_escape.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/rot_13.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/shift_jis.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/shift_jis_2004.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/shift_jisx0213.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/undefined.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/tis_620.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/unicode_escape.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_16.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_16_be.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_16_le.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_32.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_32_be.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_32_le.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_7.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_8.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/utf_8_sig.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/uu_codec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/encodings/zlib_codec.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ensurepip'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ensurepip/_bundled'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ensurepip/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ensurepip/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ensurepip/_bundled/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ensurepip/_uninstall.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/enum.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/filecmp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/fileinput.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/fnmatch.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/formatter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/fractions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ftplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/functools.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/genericpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/getopt.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/getpass.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/gettext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/glob.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/graphlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/gzip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/hashlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/heapq.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/html'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/hmac.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/html/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/html/entities.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/http'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/html/parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/http/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/http/client.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/http/cookiejar.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/http/server.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/http/cookies.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/Icons'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/autocomplete.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/autocomplete_w.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/autoexpand.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/codecontext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/calltip_w.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/calltip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/browser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/colorizer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/debugger.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/configdialog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/config_key.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/debugger_r.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/debugobj.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/debugobj_r.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/dynoption.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/delegator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/filelist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/editor.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/format.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/grep.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/help_about.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/help.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/hyperparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/history.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/htest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/mock_idle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/mock_tk.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/template.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_autocomplete.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_autocomplete_w.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_autoexpand.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_browser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_calltip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_calltip_w.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_codecontext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_colorizer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_config_key.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_configdialog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_debugger.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_debugger_r.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_debugobj.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_debugobj_r.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_delegator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_editmenu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_editor.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_filelist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_format.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_grep.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_help.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_help_about.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_history.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_hyperparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_iomenu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_macosx.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_outwin.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_multicall.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_mainmenu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_parenmatch.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_pathbrowser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_percolator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_pyparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_pyshell.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_query.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_redirector.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_replace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_rpc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_run.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_runscript.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_scrolledlist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_search.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_searchbase.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_searchengine.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_squeezer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_stackviewer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_statusbar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_sidebar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_text.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_textview.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_tooltip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_undo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_tree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_warning.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_window.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/idle_test/test_zoomheight.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/iomenu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/mainmenu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/macosx.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/multicall.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/outwin.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/parenmatch.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/pathbrowser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/percolator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/pyparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/pyshell.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/query.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/redirector.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/replace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/rpc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/runscript.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/scrolledlist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/search.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/run.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/sidebar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/searchengine.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/searchbase.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/squeezer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/stackviewer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/statusbar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/textview.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/tooltip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/tree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/window.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/undo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/zoomheight.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/imaplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/idlelib/zzdummy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/imghdr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/imp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/_bootstrap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/_bootstrap_external.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/_common.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/machinery.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/metadata.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/resources.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/importlib/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/inspect.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/io.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ipaddress.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/json'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/json/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/json/decoder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/json/encoder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/json/scanner.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/json/tool.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/keyword.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib-dynload'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/btm_matcher.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/btm_utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixer_base.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixer_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_apply.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_asserts.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_basestring.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_buffer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_dict.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_except.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_exec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_execfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_exitfunc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_filter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_funcattrs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_future.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_getcwdu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_has_key.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_idioms.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_import.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_imports.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_imports2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_input.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_intern.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_isinstance.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_itertools.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_itertools_imports.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_long.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_map.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_metaclass.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_methodattrs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_ne.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_next.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_nonzero.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_numliterals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_operator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_paren.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_print.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_raise.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_raw_input.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_reduce.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_reload.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_renames.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_repr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_set_literal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_standarderror.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_tuple_params.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_throw.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_sys_exc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_types.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_unicode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_urllib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_ws_comma.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_xrange.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_xreadlines.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/fixes/fix_zip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/main.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/patcomp.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/conv.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/driver.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/grammar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/literals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/parse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/pgen.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/token.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pgen2/tokenize.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pytree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/pygram.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/refactor.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/bom.py'...
***   File "/usr/lib64/python3.9/lib2to3/tests/data/bom.py", line 2
    print "BOM BOOM!"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("BOM BOOM!")?

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/crlf.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/different_encoding.py'...
***   File "/usr/lib64/python3.9/lib2to3/tests/data/different_encoding.py", line 3
    print u'??????????????????????????????????????????????????????????????'
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(u'??????????????????????????????????????????????????????????????')?

Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers'...
***   File "/usr/lib64/python3.9/lib2to3/tests/data/crlf.py", line 1
    print "hi"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("hi")?

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/false_encoding.py'...
***   File "/usr/lib64/python3.9/lib2to3/tests/data/false_encoding.py", line 2
    print '#coding=0'
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print('#coding=0')?

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/bad_order.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes/fix_explicit.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes/fix_first.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes/fix_last.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes/fix_parrot.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/myfixes/fix_preorder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/no_fixer_cls.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/fixers/parrot_example.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/infinite_recursion.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/py2_test_grammar.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/logging'...
***   File "/usr/lib64/python3.9/lib2to3/tests/data/py2_test_grammar.py", line 31
    self.assertEquals(0377, 255)
                         ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/pytree_idempotency.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_all_fixers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_fixers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_main.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_pytree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_refactor.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lib2to3/tests/test_util.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/linecache.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/locale.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/logging/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/dummy'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/logging/config.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/logging/handlers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/lzma.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/mailbox.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/mailcap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/mimetypes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/modulefinder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/connection.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/context.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/dummy/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/heap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/dummy/connection.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/forkserver.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/managers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/pool.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/popen_fork.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/popen_forkserver.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/popen_spawn_posix.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/popen_spawn_win32.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/process.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/queues.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/resource_sharer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/reduction.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/sharedctypes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/synchronize.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/shared_memory.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/spawn.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pydoc_data'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/netrc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ntpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/nturl2path.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/multiprocessing/resource_tracker.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/nntplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/numbers.py'...
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:664: SyntaxWarning: "is" with a literal. Did you mean "=="?
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:665: SyntaxWarning: "is not" with a literal. Did you mean "!="?
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:668: SyntaxWarning: "is" with a literal. Did you mean "=="?
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/opcode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/operator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/os.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pathlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/optparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pdb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pickle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pipes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pkgutil.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pickletools.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/platform.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/plistlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/poplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/posixpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pprint.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/site-packages'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/profile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pstats.py'...
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:664: SyntaxWarning: "is" with a literal. Did you mean "=="?
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:665: SyntaxWarning: "is not" with a literal. Did you mean "!="?
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:668: SyntaxWarning: "is" with a literal. Did you mean "=="?
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/py_compile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pty.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pyclbr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pydoc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pydoc_data/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/pydoc_data/topics.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/queue.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/quopri.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/random.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/re.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test'...
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:664: SyntaxWarning: "is" with a literal. Did you mean "=="?
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:665: SyntaxWarning: "is not" with a literal. Did you mean "!="?
/usr/lib64/python3.9/lib2to3/tests/data/py3_test_grammar.py:668: SyntaxWarning: "is" with a literal. Did you mean "=="?
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/reprlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/rlcompleter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/runpy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sched.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/secrets.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/selectors.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/shelve.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/shlex.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/shutil.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/signal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/site.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/smtpd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/smtplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sndhdr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/socket.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/socketserver.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/dbapi2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/dump.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/backup.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/dbapi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/dump.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/factory.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/hooks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/regression.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/types.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/transactions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sqlite3/test/userfunctions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sre_compile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sre_constants.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sre_parse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/ssl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/stat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/statistics.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/string.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/stringprep.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/struct.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/subprocess.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sunau.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/symbol.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/symtable.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/sysconfig.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tabnanny.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tarfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/telnetlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tempfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/_test_multiprocessing.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ann_module.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ann_module2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ann_module3.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/audiodata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/audiotests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/audit-tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/autotest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/bad_coding.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/bad_coding2.py'...
***   File "/usr/lib64/python3.9/test/bad_coding2.py", line None
SyntaxError: encoding problem: utf8 with BOM

***   File "/usr/lib64/python3.9/test/bad_coding.py", line 0
SyntaxError: unknown encoding: uft-8

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/bad_getattr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/bad_getattr2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/bad_getattr3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_3131.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_3131.py", line 2
    ? = 2
    ^
SyntaxError: invalid character '?' (U+20AC)

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future10.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future3.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_future10.py", line 3
SyntaxError: from __future__ imports must occur at the beginning of the file

***   File "/usr/lib64/python3.9/test/badsyntax_future3.py", line 3
SyntaxError: future feature rested_snopes is not defined

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future4.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_future4.py", line 3
SyntaxError: from __future__ imports must occur at the beginning of the file

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future5.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future6.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_future5.py", line 4
SyntaxError: from __future__ imports must occur at the beginning of the file

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future7.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_future6.py", line 3
SyntaxError: from __future__ imports must occur at the beginning of the file

***   File "/usr/lib64/python3.9/test/badsyntax_future7.py", line 3
SyntaxError: from __future__ imports must occur at the beginning of the file

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future8.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_future8.py", line 3
SyntaxError: future feature * is not defined

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_future9.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/badsyntax_pep3120.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_future9.py", line 3
SyntaxError: not a chance

Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/bisect_cmd.py'...
***   File "/usr/lib64/python3.9/test/badsyntax_pep3120.py", line 1
    print("b?se")
                ^
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xf6 in position 1: invalid start byte

Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/capath'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/cjkencodings'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/data'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/decimaltestdata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/coding20731.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/curses_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dataclass_module_1.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dtracedata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dataclass_module_1_str.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dataclass_module_2_str.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dataclass_module_2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/datetimetester.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dataclass_textanno.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/eintrdata'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/encoded_modules'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/imghdrdata'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dis_module.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/doctest_aliases.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/double_const.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dtracedata/call_stack.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dtracedata/gc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dtracedata/instance.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/dtracedata/line.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/eintrdata/eintr_tester.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/encoded_modules/module_iso_8859_1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/encoded_modules/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/encoded_modules/module_koi8_r.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/final_a.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/final_b.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/fork_wait.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/future_test1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/future_test2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/gdb_sample.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/good_getattr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/imp_dummy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/inspect_fodder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/inspect_fodder2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/cmdline.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/main.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/pgo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/refleak.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/save_env.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/runtest_mp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/runtest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/setup.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/libregrtest/win_utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/list_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/lock_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/make_ssl_certs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/mapping_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/memory_watchdog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/mp_fork_bomb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/mock_socket.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/mod_generics_cache.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/mp_preload.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/multibytecodec_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/pickletester.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/profilee.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/pyclbr_input.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/pydoc_mod.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/pydocfodder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/pythoninfo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/re_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/regrtest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/reperf.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/relimport.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/sample_doctest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/sample_doctest_no_docstrings.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/sample_doctest_no_doctests.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/sndhdrdata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/seq_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/signalinterproctester.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/sortperf.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ssl_servers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ssltests.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/subprocessdata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/string_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/subprocessdata/fd_status.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/subprocessdata/input_reader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/subprocessdata/qcat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/subprocessdata/qgrep.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/subprocessdata/sigchild_ignore.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/bytecode_helper.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/hashlib_helper.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/logging_helper.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/script_helper.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/socket_helper.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/support/testresult.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test___all__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test___future__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test__locale.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test__opcode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test__osx_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test__xxsubinterpreters.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_abstract_numbers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_aifc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_argparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_array.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asdl_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ast.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncgen.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asynchat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/echo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/echo2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/echo3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/functional.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_base_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_buffered_proto.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_context.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_futures.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_locks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_pep492.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_proactor_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_protocols.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_queues.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_runners.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_selector_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_sendfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_server.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_sslproto.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_sock_lowlevel.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_subprocess.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_streams.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_tasks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_threads.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_transports.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_unix_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_windows_events.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/test_windows_utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncio/utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_asyncore.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_atexit.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_audioop.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_audit.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_augassign.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_base64.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_baseexception.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bigmem.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_binascii.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bdb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_binhex.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bigaddrspace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_binop.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bisect.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bool.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_buffer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bufio.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_builtin.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bytes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_bz2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_c_locale_coercion.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_calendar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_call.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_capi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cgi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cgitb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_charmapcodec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_check_c_globals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_class.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_clinic.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cmath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cmd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cmd_line.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cmd_line_script.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_code.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_code_module.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codeccallbacks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecencodings_cn.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecencodings_hk.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/data'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecencodings_iso2022.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecencodings_jp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecencodings_kr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecencodings_tw.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecmaps_cn.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecmaps_hk.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecmaps_jp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecmaps_kr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecmaps_tw.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codecs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_codeop.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_collections.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_colorsys.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_compare.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_compile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_compileall.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_complex.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_concurrent_futures.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_configparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_contains.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_context.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_contextlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_contextlib_async.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_copy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_copyreg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_coroutines.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_cprofile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_crashers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_crypt.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_csv.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ctypes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_curses.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dataclasses.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_datetime.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dbm.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dbm_dumb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dbm_gnu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dbm_ndbm.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_decimal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_decorators.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_defaultdict.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_deque.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_descr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_descrtut.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_devpoll.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dict.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dict_version.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dictcomps.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dictviews.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_difflib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dis.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_distutils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_doctest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_doctest2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_docxmlrpc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dtrace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dynamic.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_dynamicclassattribute.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_eintr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test__encoded_words.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test__header_value_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_asian_codecs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_contentmanager.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_defect_handling.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_email.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_generator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_headerregistry.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_inversion.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_message.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_pickleable.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_policy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/test_utils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_email/torture_test.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_embed.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ensurepip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_enum.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_enumerate.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_eof.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_epoll.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_errno.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_exception_hierarchy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_exception_variations.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_exceptions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_extcall.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_faulthandler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fcntl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_file.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_file_eintr.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_filecmp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fileinput.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fileio.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_finalization.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_float.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_flufl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fnmatch.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fork1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_format.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fractions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_frame.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_frozen.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ftplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_fstring.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_funcattrs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_functools.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_future.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_future3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_future4.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_future5.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_gc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_gdb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_generator_stop.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_generators.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_genericalias.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_genericclass.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/subpkg'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_genericpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_genexps.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_getargs2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_getopt.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_getpass.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/package'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_gettext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_glob.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_global.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_grammar.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/package2'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_graphlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_grp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_gzip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_hash.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_hashlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_heapq.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_hmac.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_html.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_htmlparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_http_cookiejar.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_http_cookies.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_httplib.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/unwritable'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_httpservers.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_idle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_imaplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_imp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_imghdr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/basic.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/builtin'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/basic2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/binding.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/binding2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/from_cycle1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/from_cycle2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/indirect.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/rebinding.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/rebinding2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/source.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/subpackage.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/subpkg/subpackage2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/subpkg/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/use.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/circular_imports/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/package/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/package/submodule.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/package2/submodule1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/package2/submodule2.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/unwritable/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_import/data/unwritable/x.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/builtin/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data01'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/builtin/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/builtin/test_finder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/builtin/test_loader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data01/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data01/subdirectory'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data01/subdirectory/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data02'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data02/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data02/one'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data02/one/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data02/two'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data02/two/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03/namespace'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03/namespace/portion1'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03/namespace/portion1/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03/namespace/portion2'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/data03/namespace/portion2/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension/test_case_sensitivity.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension/test_finder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension/test_loader.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/frozen'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/extension/test_path_hook.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/fixtures.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/frozen/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/frozen/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/frozen/test_finder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/frozen/test_loader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test___loader__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test___package__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_api.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_caching.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_fromlist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_meta_path.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_packages.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_path.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/import_/test_relative_imports.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/both_portions'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/both_portions/foo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/both_portions/foo/one.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/both_portions/foo/two.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/module_and_namespace_package'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/module_and_namespace_package/a_test'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/module_and_namespace_package/a_test.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/not_a_namespace_pkg'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/not_a_namespace_pkg/foo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/not_a_namespace_pkg/foo/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/portion1'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/not_a_namespace_pkg/foo/one.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/portion1/foo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/portion1/foo/one.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/portion2'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/portion2/foo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/portion2/foo/two.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project1'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project1/parent'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project1/parent/child'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project1/parent/child/one.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project2'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project2/parent'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project2/parent/child'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project3'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project3/parent'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project2/parent/child/two.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project3/parent/child'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/namespace_pkgs/project3/parent/child/three.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/test_case_sensitivity.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/test_file_loader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/test_finder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/test_source_encoding.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/source/test_path_hook.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/stubs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_api.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_abc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_files.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_lazy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_locks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_main.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_metadata_api.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_namespace_pkgs.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_open.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_path.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_pkg_import.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_read.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_resource.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_threaded_import.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_spec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_windows.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/test_zip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/threaded_import_hangers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/util.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/zipdata01'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/zipdata01/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/zipdata02'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_importlib/zipdata02/__init__.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_index.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_inspect.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_int.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_int_literal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_io.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ipaddress.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ioctl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_isinstance.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_iter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_iterlen.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_itertools.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_decode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_default.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_dump.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_encode_basestring_ascii.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_fail.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_float.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_enum.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_indent.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_pass1.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_pass3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_recursion.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_scanstring.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_pass2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_speedups.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_tool.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_separators.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_json/test_unicode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_keyword.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_keywordonlyarg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_largefile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_kqueue.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_lib2to3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_list.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_linecache.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_listcomps.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_lltrace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_locale.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_logging.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_longexp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_long.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_lzma.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_mailbox.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_mailcap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_marshal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_math.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_memoryio.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_memoryview.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_metaclass.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_mimetypes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_mmap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_minidom.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_module.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_modulefinder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_msilib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_multibytecodec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_multiprocessing_fork.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_multiprocessing_forkserver.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_multiprocessing_main_handling.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_multiprocessing_spawn.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_named_expressions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_netrc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_nis.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_nntplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ntpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_numeric_tower.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_opcodes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_openpty.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_operator.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_optparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ordered_dict.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_os.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ossaudiodev.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_osx_env.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_parser.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_generator'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pathlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pdb.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peepholer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_generator/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_generator/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_generator/test_c_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_generator/test_first_sets.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_generator/test_pegen.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_peg_parser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pickle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_picklebuffer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pickletools.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pipes.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pkg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pkgutil.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_platform.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_plistlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_poll.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_popen.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_poplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_positional_only_arg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_posix.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_posixpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pow.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pprint.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_print.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_profile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_property.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pty.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pulldom.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pwd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_py_compile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pyclbr.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pydoc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_queue.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pyexpat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_quopri.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_pstats.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_raise.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_random.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_range.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_re.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_readline.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_regrtest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_repl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_reprlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_resource.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_richcmp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_rlcompleter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_runpy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_robotparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sax.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_warnings'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sched.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_scope.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_warnings/data'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_script_helper.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_secrets.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_select.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_selectors.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_set.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_setcomps.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_shelve.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_shlex.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_signal.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_shutil.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_site.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_slice.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_smtpd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_smtplib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_smtpnet.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sndhdr.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_socket.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_socketserver.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sort.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_source_encoding.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_spwd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sqlite.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ssl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_startfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_stat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_statistics.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_strftime.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_string.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_string_literals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_stringprep.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_strptime.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo/data'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_strtod.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_struct.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_structmembers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_structseq.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_subclassinit.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_subprocess.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sunau.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sundry.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_super.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_symbol.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_symtable.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_syntax.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sys.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sys_setprofile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sys_settrace.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/tracedmodules'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_sysconfig.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_syslog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tabnanny.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/xmltestdata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tarfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tcl.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_telnetlib.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/xmltestdata/c14n-20'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tempfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_textwrap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_thread.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_threadedtempfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_threading.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_threading_local.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_threadsignals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_time.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_timeit.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_timeout.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tix.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tk.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ziptestdata'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tokenize.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_fixcid.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_gprof2html.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_i18n.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_lll.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_md5sum.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_pathfix.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_pdeps.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_pindent.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_reindent.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tools/test_sundry.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_trace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_traceback.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tracemalloc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ttk_guionly.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ttk_textonly.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_tuple.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_turtle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_type_comments.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_typechecks.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_types.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_ttk'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_typing.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_ucn.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unary.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unicode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unicode_file.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unicode_file_functions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unicode_identifiers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unicodedata.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unittest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_univnewlines.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unpack.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unpack_ex.py'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/venv'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/venv/scripts'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/venv/scripts/common'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/venv/scripts/posix'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/etree'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/parsers'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xmlrpc'...
Listing '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zoneinfo'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_unparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urllib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urllib2.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urllib2_localnet.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urllib2net.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urllib_response.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urllibnet.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_urlparse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_userdict.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_userlist.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_userstring.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_utf8_mode.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_utf8source.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_uu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_uuid.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_venv.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_wait3.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_wait4.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_warnings/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_warnings/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_warnings/data/import_warning.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_warnings/data/stacklevel.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_wave.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_weakref.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_weakset.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_webbrowser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_winconsoleio.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_winreg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_winsound.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_with.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_wsgiref.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xdrlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xml_dom_minicompat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xml_etree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xml_etree_c.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xmlrpc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xmlrpc_net.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_xxtestfuzz.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_yield_from.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zipapp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zipfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zipfile64.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zipimport.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zipimport_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo/_support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo/data/update_test_data.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/test_zoneinfo/test_zoneinfo.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/testcodec.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/tf_inherit_check.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/time_hashlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/tracedmodules/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/tracedmodules/testmod.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/win_console_handler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/xmltests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/test/ziptestdata/testdata_module_inside_zip.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/textwrap.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/this.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/threading.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/timeit.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/colorchooser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/constants.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/commondialog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/dialog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/dnd.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/filedialog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/font.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/messagebox.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/scrolledtext.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/simpledialog.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/runtktests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_font.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_geometry_managers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_images.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_loadtk.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_misc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_text.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_widgets.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_tkinter/test_variables.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_ttk/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_ttk/test_extensions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_ttk/test_functions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_ttk/test_style.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/test_ttk/test_widgets.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/test/widget_tests.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/tix.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tkinter/ttk.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/token.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tokenize.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/trace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/traceback.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tracemalloc.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/tty.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtle.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/bytedesign.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/chaos.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/colormixer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/clock.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/forest.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/fractalcurves.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/lindenmayer.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/minimal_hanoi.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/nim.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/paint.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/peace.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/penrose.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/rosette.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/planet_and_moon.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/round_dance.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/sorting_animate.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/tree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/yinyang.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/turtledemo/two_canvases.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/types.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/typing.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/_log.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/async_case.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/case.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/loader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/main.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/mock.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/result.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/runner.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/signals.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/suite.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/_test_warnings.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/dummy.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_assertions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_async_case.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_break.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_case.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_discovery.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_functiontestcase.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_loader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_program.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_result.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_runner.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_setups.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_skipping.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/test_suite.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/support.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testasync.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testcallable.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testhelpers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testmagicmethods.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testmock.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testpatch.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testsealable.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testsentinel.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/test/testmock/testwith.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/unittest/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib/error.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib/parse.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib/request.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib/response.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/urllib/robotparser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/uu.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/uuid.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/venv/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/venv/__main__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/warnings.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wave.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/weakref.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/webbrowser.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref/handlers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref/headers.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref/simple_server.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref/util.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/wsgiref/validate.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xdrlib.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/NodeFilter.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/domreg.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/expatbuilder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/minicompat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/minidom.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/pulldom.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/dom/xmlbuilder.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/etree/ElementInclude.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/etree/ElementPath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/etree/ElementTree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/etree/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/etree/cElementTree.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/parsers/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/parsers/expat.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax/_exceptions.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax/expatreader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax/handler.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax/saxutils.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xml/sax/xmlreader.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xmlrpc/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xmlrpc/client.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/xmlrpc/server.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zipapp.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zipfile.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zipimport.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zoneinfo/__init__.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zoneinfo/_common.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zoneinfo/_tzpath.py'...
Compiling '/home/tkloczko/rpmbuild/BUILDROOT/python-3.9.0-0.2.b5.fc33.x86_64/usr/lib64/python3.9/zoneinfo/_zoneinfo.py'...

----------
messages: 374222
nosy: kloczek
priority: normal
severity: normal
status: open
title: Errors and warnings on generate butecode files
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41390>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:59:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 02:59:21 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595645961.3.0.289909592627.issue41388@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(While I wrote the following, Lewis Ball posted some of the same conclusions.)

0. I verified the failure with 3.8.5 and current master.

1. I reduced the failing example to a minimum of 7 chars on 2 lines.
(
else)

1a. Deleting '\n' or any letter of 'else' fixes the problem.
1b. Adding 'else' before '(' fixes the problem.
1a is true for the initial 'else' on line 4 of the original example.
1b is true for 'else' on a new line before the first.

2. I tried multiple variations
2a. Matching also fails when typing ')'.
2b. Replacing '()' with '[]' or '{}' makes no difference.

2c. Replacing 'else' with 'elif', 'while', 'def', or 'class' makes no difference.  This include the addition for 1b above.  Replacing 'else' with 'if', 'for', or 'with' fixes the bug.

Bingo!!!  Matching uses idlelib.hyperparser, which uses idlelib.pyparse, which has regex _synchre, which finds "what looks like the start of a popular statement".  It matches 'elif', etcetera, but not 'if', etcetera.  I noticed previously that these 'popular' line beginners were missing and have planned to add them.*  But we need to make matched words not disable fence matching.

* Keyword 'with' was likely added to python after this re was last revised.  Keywords 'if' and 'for' might have been removed when comprehensions were added. If so, 'else' should have been removed when conditional expressions were added and 'yield' when yield expressions were added.  These latter two are the only keywords matched by _synchre that can properly appear in the middle of a statement but at the beginning of a continuation line.

2d. In the original and minimal examples, moving the offending 'else' to the end of the previous line fixes the problem.  So I believe that 'else' at the beginning of the line is seen marking the beginning of the statememt, and matching does not look back further.  If 'else' and 'yield' were left in _synchre and 'if' and 'for' were added back, the matcher would have to determine whether the line is a continuation or not.  (And I believe that not having 'if' and 'for' degrades the use of pyparse at least for other uses.)

2e. The minimal failing example works in the shell.  Why are _synchre keywords not poisonous here?  Is it just because the current statement is known to begin just after the '>>> ' prompt, so that else beginning the second line is somehow not seen as beginning a new statement?  We need to check if and how fence matching in shell is different other than the presence of the marker where code input begins.


Alexey: in msg371076 of #21756 I claimed that there is no issue with typing closers or ^0 on the same line just before the closer.  Thank you for reporting this counter-example.  I imagine that you are not the first IDLE user to write a conditional expression on 2 or more lines with else at the beginning of a line.  Such expressions always need a closer.

----------
nosy: +taleinat -Lewis Ball
stage:  -> test needed
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:16:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:16:04 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595646964.81.0.733522048821.issue41388@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Without rereading hyperparser and pyparse, I don't understand why a previous _synchre match prevents subsequent failures.  It does suggest that when matching parentheses, a fix would be to temporarily prepend 'else\n' to the text, or otherwise simulating the effect of that.

But the previous 'else' might only work before the 'current' statement.  And we should determine whether any other uses of these modules have related bugs.  Also, removing 'else' from the _synchre regex did not fix the issue, so there is something else I am missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:18:15 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:18:15 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595647095.7.0.135670166869.issue41388@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +Lewis Ball

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:19:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:19:10 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595647150.51.0.414783282537.issue41388@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Lewis, removing you was an accident.  Your post is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:21:03 2020
From: report at bugs.python.org (Tomasz Kloczko)
Date: Sat, 25 Jul 2020 03:21:03 +0000
Subject: [issue41390] Errors and warnings on generate bytecode files
In-Reply-To: <1595644759.87.0.69067267227.issue41390@roundup.psfhosted.org>
Message-ID: <1595647263.89.0.036763270472.issue41390@roundup.psfhosted.org>


Change by Tomasz Kloczko <kloczko.tomasz at gmail.com>:


----------
title: Errors and warnings on generate butecode files -> Errors and warnings on generate bytecode files

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41390>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:21:39 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:21:39 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595647299.94.0.534527937434.issue41373@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 0dd463c8a4269137ebed7cc29605c555030df94f by Serhiy Storchaka in branch 'master':
bpo-41373: IDLE: Fix saving files loaded with no newlines or mixed newlines (GH-21597)
https://github.com/python/cpython/commit/0dd463c8a4269137ebed7cc29605c555030df94f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:21:54 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 03:21:54 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595647314.3.0.0639063326227.issue41373@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +20752
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21610

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:22:02 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 03:22:02 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595647322.13.0.750613129713.issue41373@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20753
pull_request: https://github.com/python/cpython/pull/21611

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:38:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 03:38:52 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595648332.84.0.684381380836.issue41373@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1c562ced2123f4d5a250fe9072ac93504cc41967 by Miss Islington (bot) in branch '3.8':
bpo-41373: IDLE: Fix saving files loaded with no newlines or mixed newlines (GH-21597)
https://github.com/python/cpython/commit/1c562ced2123f4d5a250fe9072ac93504cc41967


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:39:34 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 03:39:34 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595648374.77.0.562948857061.issue41373@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 15fdbb7145ee99abd98b4968307d4b89dd71a988 by Miss Islington (bot) in branch '3.9':
bpo-41373: IDLE: Fix saving files loaded with no newlines or mixed newlines (GH-21597)
https://github.com/python/cpython/commit/15fdbb7145ee99abd98b4968307d4b89dd71a988


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:47:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:47:20 +0000
Subject: [issue41328] Hudson CI is not available anymore
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595648840.3.0.396896221687.issue41328@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After reading the Wikipedia article, I agree with removing Hudson.

The text is the same in the master branch (future 3.10), so make a PR against master.  We will backport to 3.9 and 3.8 from there. 

Jenkins is already mentioned. So replace 'or Hudson' with 'Travis-CI, or AppVeyor', each linked to its home page as the others are.  Please sign the Contributor Agreement *before* submitting a PR.
https://www.python.org/psf/contrib/

----------
nosy: +terry.reedy
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:48:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:48:12 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595648892.31.0.280010707783.issue41328@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Hudson CI is not available anymore -> In unittest doc, replace Hudson CI with Travis and Appveyor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:48:06 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 25 Jul 2020 03:48:06 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1595648886.41.0.417546797395.issue24955@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hugo, I'd welcome such a change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:56:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 03:56:51 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1595649411.25.0.0439345604506.issue37309@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +20754
pull_request: https://github.com/python/cpython/pull/21612

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:11:30 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 04:11:30 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1595650290.82.0.668899634249.issue37309@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +20755
pull_request: https://github.com/python/cpython/pull/21613

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:28:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 04:28:17 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595651297.53.0.487703408034.issue41344@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python 3.10.0a0  Jul 23 2020, win32 (without patch)

>>> from multiprocessing import shared_memory
>>> shm_a = shared_memory.SharedMemory(create=True, size=0)
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    shm_a = shared_memory.SharedMemory(create=True, size=0)
  File "f:\dev\3x\lib\multiprocessing\shared_memory.py", line 129, in __init__
    h_map = _winapi.CreateFileMapping(
OSError: [WinError 87] The parameter is incorrect: 'wnsm_4ab39616'

After the patch, I get the value error.

----------
nosy: +terry.reedy
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:31:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 04:31:04 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1595651464.28.0.264775120571.issue37309@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset af08db7bac3087aac313d052c1a6302bee7c9c89 by Terry Jan Reedy in branch 'master':
bpo-37309: NEWS for #41373 (GH-21612)
https://github.com/python/cpython/commit/af08db7bac3087aac313d052c1a6302bee7c9c89


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:31:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 04:31:08 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1595651468.46.0.32509281459.issue37309@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20756
pull_request: https://github.com/python/cpython/pull/21614

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:33:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 04:33:04 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1595651584.94.0.746349773198.issue37309@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset a667e1c66a62d509c39d30abf11778213a1e1ca0 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-37309: NEWS for #41373 (GH-21612)
https://github.com/python/cpython/commit/a667e1c66a62d509c39d30abf11778213a1e1ca0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:37:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 04:37:30 +0000
Subject: [issue41390] Errors and warnings on generate bytecode files
In-Reply-To: <1595644759.87.0.69067267227.issue41390@roundup.psfhosted.org>
Message-ID: <1595651850.74.0.99467903035.issue41390@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The warnings are from lib2to3 test data files that explicitly contain Python 2 syntax to verify if running 2to3 over those files does correct transformation. The other errors are test files for syntax error.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41390>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:40:37 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 04:40:37 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595652037.09.0.762285866012.issue41349@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What is 'it' in 'it works even after restart'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:42:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 04:42:30 +0000
Subject: [issue41350] Use of zipfile.Path causes attempt to write after
 ZipFile is closed
In-Reply-To: <1595261389.35.0.991424986164.issue41350@roundup.psfhosted.org>
Message-ID: <1595652150.44.0.875256031704.issue41350@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Not sure if it's related to this issue there is an existing issue with ZipFile.__del__ : issue37773

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41350>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:46:54 2020
From: report at bugs.python.org (Anand Tripathi)
Date: Sat, 25 Jul 2020 04:46:54 +0000
Subject: [issue41381] Google chat handler in Logging module
In-Reply-To: <1595627985.95.0.451195292693.issue41381@roundup.psfhosted.org>
Message-ID: <CAPL-qYnu6=mXG91HaFcp_zCQUecV3h=ri7WFmausz=p7DdF9Gg@mail.gmail.com>


Anand Tripathi <anand.tripathi507 at gmail.com> added the comment:

Got it, thanks!
Yeah this enhancement is so particular to Google and cannot be a part of
core library. I will create a pypi library of that.

Thanks a lot for quick responses.

Best,
Anand Tripathi

On Sat, 25 Jul 2020, 03:30 Vinay Sajip, <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> Agreed that a library on PyPI is the appropriate way to resolve this.
>
> ----------
> stage:  -> resolved
> status: pending -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41381>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41381>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:48:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 04:48:10 +0000
Subject: [issue39830] zipfile.Path is not included in __all__
In-Reply-To: <1583176669.44.0.585908649046.issue39830@roundup.psfhosted.org>
Message-ID: <1595652490.32.0.338083371697.issue39830@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing it as resolved. Thanks Zackery and jaraco.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39830>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:53:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 04:53:59 +0000
Subject: [issue41336] Sporadic segfaults during zoneinfo object creation
 stopped using Ctrl-C
In-Reply-To: <1595099141.79.0.268322250341.issue41336@roundup.psfhosted.org>
Message-ID: <1595652839.21.0.733922367797.issue41336@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing it as resolved. Thanks Zackery.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41336>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:00:43 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 25 Jul 2020 05:00:43 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595653243.79.0.879757026202.issue41340@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

What's change for the performance benchmark?

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:27:07 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 05:27:07 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595654827.9.0.716272839947.issue41380@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

It has been awhile since we added anything to turtledemo, so this is plausible.  It might be more interesting than some of the others.  I will take a look.

Until I do, I won't worry about maintenance.  I and someone else fixed up the driver in summer 2014 and I then reviewed and corrected bugs in the examples.  There has only been trivial changes since.

Some requirements for turtledemo files are listed in turtledemo.__main__.  Ehsonjon, did you read these and do you think your code complies?

----------
assignee:  -> terry.reedy
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:28:44 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 05:28:44 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595654924.06.0.338315254348.issue41380@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ehsonjon, 'fixed' means the the PR has be merged.

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:42:10 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sat, 25 Jul 2020 05:42:10 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595655730.74.0.181062748727.issue41344@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Hi, The patch aims to raise a value error, because before the patch also, ValueError was being raised in case size was negative. That's why I thought it would be correct behaviour if I raise ValueError in case size is 0.

Do you mean to say, that OSError should be raise in the case size=0.
Also, I think handling of Windows was fine even before the patch, it was MacOS and Linux which were causing problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:42:39 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 05:42:39 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595608557.6.0.839758343082.issue41387@roundup.psfhosted.org>
Message-ID: <1595655759.6.0.0277130090467.issue41387@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Antonio, when replying by email, please delete the quoted message (except possibly for a line or two that you want to quote).  When posted on the web page, the quote is distracting noise that takes up vertical space.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:44:58 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sat, 25 Jul 2020 05:44:58 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595655898.85.0.694115759967.issue41344@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Also, Linux created the shared memory with the passed name if size = 0, but threw error when it was being mapped to the process's virtual memory. Therefore, this scenario should be prevented before actually creating the shared memory segment in cases of Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:47:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 05:47:53 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595656073.96.0.158971490116.issue41344@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

No, I think ValueError on all systems is better.  I have no idea what 'wnsm_4ab39616' is about other than something internal to Windows.  It does not say what to do to correct the call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 04:38:51 2020
From: report at bugs.python.org (5YN15T3R_742 SeT1aP DeTiK)
Date: Sat, 25 Jul 2020 08:38:51 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595666331.25.0.126795653949.issue41344@roundup.psfhosted.org>


Change by 5YN15T3R_742 SeT1aP DeTiK <synx742 at gmail.com>:


Added file: https://bugs.python.org/file49338/lose.html

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 04:43:13 2020
From: report at bugs.python.org (5YN15T3R_742 SeT1aP DeTiK)
Date: Sat, 25 Jul 2020 08:43:13 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595666593.79.0.918456410496.issue41344@roundup.psfhosted.org>


Change by 5YN15T3R_742 SeT1aP DeTiK <synx742 at gmail.com>:


Added file: https://bugs.python.org/file49339/-.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 04:54:03 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 08:54:03 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595667243.62.0.669519059167.issue41344@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


Removed file: https://bugs.python.org/file49338/lose.html

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 04:54:15 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 08:54:15 +0000
Subject: [issue41344] SharedMemory crash when size is 0
In-Reply-To: <1595230536.74.0.865685098947.issue41344@roundup.psfhosted.org>
Message-ID: <1595667255.53.0.707289043117.issue41344@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


Removed file: https://bugs.python.org/file49339/-.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41344>
_______________________________________

From report at bugs.python.org  Sat Jul 25 04:58:20 2020
From: report at bugs.python.org (Nico)
Date: Sat, 25 Jul 2020 08:58:20 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595667500.75.0.391640061235.issue41386@roundup.psfhosted.org>


Nico <nicofroehlich at icloud.com> added the comment:

Yeah I see the point.

To me it does make no sense because even in the windows API they seam to not know whether to use a ulong or a uint nor does this reflect the actual depiction within the program. 

However it is probably not worth implementing a flag for that nor to change the behavior entirely. This will create more problems than it would fix ambiguity. 

Thanks for taking the time and sorry for the inconvenience.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Sat Jul 25 06:26:54 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 25 Jul 2020 10:26:54 +0000
Subject: [issue41391] Make test_unicodedata pass when running without network
Message-ID: <1595672814.77.0.412111562602.issue41391@roundup.psfhosted.org>


New submission from Chih-Hsuan Yen <yan12125 at gmail.com>:

I setup a buildbot worker to test Python 3.x on Android monthly. This month network in the Android emulator is broken and I got an additional test failure:

0:05:28 load avg: 1.21 [376/423/11] test_unicodedata failed
test test_unicodedata failed -- Traceback (most recent call last):
  File "/data/local/tmp/lib/python3.10/urllib/request.py", line 1342, in do_open
    h.request(req.get_method(), req.selector, req.data, headers,
socket.gaierror: [Errno 7] No address associated with hostname

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/lib/python3.10/test/test_unicodedata.py", line 329, in test_normalization
    testdata = open_urlresource(TESTDATAURL, encoding="utf-8",
urllib.error.URLError: <urlopen error [Errno 7] No address associated with hostname>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/lib/python3.10/test/test_unicodedata.py", line 335, in test_normalization
    self.fail(f"Could not retrieve {TESTDATAURL}")
AssertionError: Could not retrieve http://www.pythontest.net/unicode/13.0.0/NormalizationTest.txt

I propose wrapping the test in socket_helper.transient_internet() so that this test is skipped if the Internet is not available.

----------
components: Tests
messages: 374249
nosy: yan12125
priority: normal
severity: normal
status: open
title: Make test_unicodedata pass when running without network
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41391>
_______________________________________

From report at bugs.python.org  Sat Jul 25 06:38:12 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 25 Jul 2020 10:38:12 +0000
Subject: [issue41391] Make test_unicodedata pass when running without network
In-Reply-To: <1595672814.77.0.412111562602.issue41391@roundup.psfhosted.org>
Message-ID: <1595673492.25.0.459937439254.issue41391@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
keywords: +patch
pull_requests: +20757
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21615

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41391>
_______________________________________

From report at bugs.python.org  Sat Jul 25 06:41:29 2020
From: report at bugs.python.org (Antonio Gutierrez)
Date: Sat, 25 Jul 2020 10:41:29 +0000
Subject: [issue41387] Escape needed in the email documentation example
In-Reply-To: <1595655759.6.0.0277130090467.issue41387@roundup.psfhosted.org>
Message-ID: <CANaRyDiw15Mmzk+KNzVeDLjT=F8WgRLR3MZPO4FPnXOC9O3BJA@mail.gmail.com>


Antonio Gutierrez <antdcs at gmail.com> added the comment:

>
> OK, I will do that.
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41387>
_______________________________________

From report at bugs.python.org  Sat Jul 25 07:27:37 2020
From: report at bugs.python.org (Tomasz Kloczko)
Date: Sat, 25 Jul 2020 11:27:37 +0000
Subject: [issue41390] Errors and warnings on generate bytecode files
In-Reply-To: <1595644759.87.0.69067267227.issue41390@roundup.psfhosted.org>
Message-ID: <1595676457.94.0.415756215909.issue41390@roundup.psfhosted.org>


Tomasz Kloczko <kloczko.tomasz at gmail.com> added the comment:

Issue is that this command ends with non-zero exit code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41390>
_______________________________________

From report at bugs.python.org  Sat Jul 25 07:58:35 2020
From: report at bugs.python.org (Philip R Brenan)
Date: Sat, 25 Jul 2020 11:58:35 +0000
Subject: [issue41392] Syntax error rather than run time error
Message-ID: <1595678315.6.0.422536039763.issue41392@roundup.psfhosted.org>


New submission from Philip R Brenan <philiprbrenan at gmail.com>:

a = false

# Traceback (most recent call last):
#   File "test.py", line 1, in <module>
#     a = false
# NameError: name 'false' is not defined
# Compilation finished successfully.

Please make this a syntax error rather than a run time error as the user intention is obvious and there cannot possibly be a variable called 'false' yet.

----------
components: Build
messages: 374252
nosy: philiprbrenan at gmail.com
priority: normal
severity: normal
status: open
title: Syntax error rather than run time error
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41392>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:20:34 2020
From: report at bugs.python.org (Edward K Ream)
Date: Sat, 25 Jul 2020 12:20:34 +0000
Subject: [issue33337] Provide a supported Concrete Syntax Tree implementation
 in the standard library
In-Reply-To: <1524445447.99.0.682650639539.issue33337@psf.upfronthosting.co.za>
Message-ID: <1595679634.0.0.429309093304.issue33337@roundup.psfhosted.org>


Edward K Ream <edreamleo at gmail.com> added the comment:

Hello all,

This is a "sideways" response to this issue. I have been dithering about whether to give you a heads up. I hope you won't mind...

I have just announced the leoAst.py on python-announce-list. You can read the announcement here: 

https://github.com/leo-editor/leo-editor/issues/1565#issuecomment-654904747

Imo, leoAst.py solves many of the concerns mentioned in the first comment of this thread. leoAst.py is certainly a different approach.

Also imo, the TOG and TOG in leoAst.py plug significant holes in python's ast and tokenize modules. These classes might be candidates for python's ast module. If you're interested, I will be willing to do further work. If not, I completely understand.

As shown in the project's history, a significant amount of invention and discovery was required. The root of much of my initial confusion and difficulties was the notion that "real programmers don't use tokens". In fact, I discovered that the reverse is true. Tokens contain the ground truth. In many cases, the parse tree doesn't.

I would be interested in your reactions.

----------
nosy: +edreamleo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33337>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:21:28 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 12:21:28 +0000
Subject: [issue41392] SyntaxError rather than NameError error
In-Reply-To: <1595678315.6.0.422536039763.issue41392@roundup.psfhosted.org>
Message-ID: <1595679688.47.0.201666200234.issue41392@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

There is nothing *wrong* with the syntax; it's just a regular assignment.
It's not something like `False = 4` or `while = 6` which '=' is invalid.

----------
nosy: +wyz23x2
title: Syntax error rather than run time error -> SyntaxError rather than NameError error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41392>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:21:35 2020
From: report at bugs.python.org (Tim Z)
Date: Sat, 25 Jul 2020 12:21:35 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595679695.52.0.589026061315.issue41349@roundup.psfhosted.org>


Tim Z <timour1712 at gmail.com> added the comment:

idle shell window
https://imgur.com/zuyuOaS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:21:38 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 12:21:38 +0000
Subject: [issue41392] SyntaxError rather than NameError
In-Reply-To: <1595678315.6.0.422536039763.issue41392@roundup.psfhosted.org>
Message-ID: <1595679698.26.0.411818761319.issue41392@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
title: SyntaxError rather than NameError error -> SyntaxError rather than NameError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41392>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:27:07 2020
From: report at bugs.python.org (Constant Marks)
Date: Sat, 25 Jul 2020 12:27:07 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
In-Reply-To: <1595351360.26.0.0463175809492.issue41362@roundup.psfhosted.org>
Message-ID: <1595680027.4.0.174656388295.issue41362@roundup.psfhosted.org>


Constant Marks <crmarksv at gmail.com> added the comment:

Maybe I am doing something wrong.  I fetched the 3.10 alpha release, made a simple edit to line 93 in Grammer. 

pass_stmt: 'pass' | 'proceed'

Ran: 
>build.bat -d --regen

Successfully compiles with:
warning : Pegen updated. You will need to rebuild pythoncore to see the changes.

So I run:
> build.bat -d

But after all this I still get the runtime Name error that 'proceed' is not defined.

I have tried build.bat -t:cCleanAll bit it still does not work.  

Are there some extra steps with the new PEG parser?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:26:42 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 12:26:42 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595680002.39.0.39984977465.issue41384@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
type:  -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:30:25 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2020 12:30:25 +0000
Subject: [issue41392] SyntaxError rather than NameError
In-Reply-To: <1595678315.6.0.422536039763.issue41392@roundup.psfhosted.org>
Message-ID: <1595680225.4.0.981804887184.issue41392@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The compiler cannot know if "false" is an existing name when compiling. 

One example is that the name might refer to the name of a builtin.

----------
nosy: +ronaldoussoren
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41392>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:38:04 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 12:38:04 +0000
Subject: [issue41393] Fix FAQ example to use __import__('functools').reduce
Message-ID: <1595680684.82.0.451241324021.issue41393@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

https://docs.python.org/3/faq/programming.html#is-it-possible-to-write-obfuscated-one-liners-in-python
https://github.com/python/cpython/blob/3.8/Doc/faq/programming.rst
The 3rd raises a NameError because reduce was moved into functools. __import__('functools').reduce should fix this.

----------
assignee: docs at python
components: Documentation
messages: 374258
nosy: docs at python, wyz23x2
priority: normal
severity: normal
status: open
title: Fix FAQ example to use __import__('functools').reduce
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/issue41393>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:47:43 2020
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Sat, 25 Jul 2020 12:47:43 +0000
Subject: [issue41393] Fix FAQ example to use __import__('functools').reduce
In-Reply-To: <1595680684.82.0.451241324021.issue41393@roundup.psfhosted.org>
Message-ID: <1595681263.56.0.97167385274.issue41393@roundup.psfhosted.org>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

It doesn't raise an error when you run the whole example, it has "from functools import reduce" at the top.

----------
nosy: +cryvate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41393>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:49:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2020 12:49:19 +0000
Subject: [issue41393] Fix FAQ example to use __import__('functools').reduce
In-Reply-To: <1595680684.82.0.451241324021.issue41393@roundup.psfhosted.org>
Message-ID: <1595681359.28.0.552509914584.issue41393@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41393>
_______________________________________

From report at bugs.python.org  Sat Jul 25 08:54:29 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 12:54:29 +0000
Subject: [issue41394] Behiavior of '_' strange in shell
Message-ID: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

>>> (None and True)
>>> print(_)
False
>>> print((None and True))  # Not same?!
None
>>> 

This isn't right.

P.S. What component should this be? IDLE? It's the shell, not just IDLE. Core? Not that deep!

----------
messages: 374260
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Behiavior of '_' strange in shell
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:09:45 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 25 Jul 2020 13:09:45 +0000
Subject: [issue41394] Behiavior of '_' strange in shell
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595682585.56.0.528734678803.issue41394@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi wyz23x2, did you do that from a clean interpreter?

_ is set to the last non-None result: https://github.com/python/cpython/blob/dd8a93e23b5c4f9290e1cea6183d97eb9b5e61c0/Python/sysmodule.c#L690-L696

So what you are seeing is that (None and True) is None, but _ is set to some value that you got from a previous input.

I think the component for this report is "Interpreter core".

----------
components: +Interpreter Core
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:12:46 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 25 Jul 2020 13:12:46 +0000
Subject: [issue41394] Behiavior of '_' strange in shell
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595682766.95.0.467791027448.issue41394@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

This behaviour is documented at https://docs.python.org/3/library/sys.html#sys.displayhook.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:21:44 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 13:21:44 +0000
Subject: [issue41394] Make '_' behavior in shell more clear
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595683304.74.0.509621860653.issue41394@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

I think this should be documented more clearly. Or else users might feel surprised:
>>> print(123)
123
>>> _
Traceback (most recent call last):                                                                                            
    File "<stdin>", line 1, in <module>                                                                                       
NameError: name '_' is not defined 
>>> # There is an expression!?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Behiavior of '_' strange in shell -> Make '_' behavior in shell more clear

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:25:04 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Jul 2020 13:25:04 +0000
Subject: [issue41394] Make '_' behavior in shell more clear
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595683504.07.0.0923638818966.issue41394@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I haven't checked to see what's documented. I'm sure we'd accept a patch that improves the documentation if it's lacking.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:29:30 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Jul 2020 13:29:30 +0000
Subject: [issue41393] Fix FAQ example to use __import__('functools').reduce
In-Reply-To: <1595680684.82.0.451241324021.issue41393@roundup.psfhosted.org>
Message-ID: <1595683770.16.0.549595841101.issue41393@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that the example is okay as-is.

Plus, I can't see us using __import__ in examples. "import" is the preferred way to load modules.

Although now that I think about it, maybe __import__ would fit in with the subject "Is it possible to write obfuscated one-liners in Python?"!

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41393>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:32:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 13:32:19 +0000
Subject: [issue41394] Make '_' behavior in shell more clear
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595683939.38.0.53240675559.issue41394@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There is also some docs for _ at https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:36:52 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 13:36:52 +0000
Subject: [issue41394] Document '_' in interpreter in shell tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595684212.43.0.618203739161.issue41394@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

But there's nothing in https://docs.python.org/3/tutorial/interpreter.html. It should be stated there.

----------
components:  -Interpreter Core
nosy:  -xtreak
title: Make '_' behavior in shell more clear -> Document '_' in interpreter in shell tutorial

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:37:16 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 13:37:16 +0000
Subject: [issue41394] Document '_' in interpreter in shell tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595684236.9.0.118611913883.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:49:41 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Jul 2020 13:49:41 +0000
Subject: [issue41392] SyntaxError rather than NameError
In-Reply-To: <1595678315.6.0.422536039763.issue41392@roundup.psfhosted.org>
Message-ID: <1595684981.44.0.3509133351.issue41392@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

As an example of why it's not possible for the compiler to treat this as a syntax error: I use python for my config files. Before I load these files, I inject names into the builtins, so that the config files can reference them. Some of these are constants, others are callbacks. "false" or anything else could be one of the injected names.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41392>
_______________________________________

From report at bugs.python.org  Sat Jul 25 10:12:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jul 2020 14:12:10 +0000
Subject: [issue41395] pickle and pickletools cli interface doesn't close input
 and output file.
Message-ID: <1595686330.63.0.838691465271.issue41395@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

pickle and pickletools use argparse with FileType which is not automatically closed. Other cli interfaces like json [0], ast [1] use context manager to close filetype objects.

pickle : https://github.com/python/cpython/blob/af08db7bac3087aac313d052c1a6302bee7c9c89/Lib/pickle.py#L1799

mypickle

>>> import pickle
>>> with open("mypickle", "wb") as f: pickle.dump({"a": 1}, f)

./python -Wall -m pickle mypickle                    
{'a': 1}
sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='mypickle'>

pickletools : https://github.com/python/cpython/blob/af08db7bac3087aac313d052c1a6302bee7c9c89/Lib/pickletools.py#L2850-L2855

./python -Wall -m pickletools mypickle -o mypickle.py
sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='mypickle'>
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='mypickle.py' mode='w' encoding='UTF-8'>


[0] https://github.com/python/cpython/blob/af08db7bac3087aac313d052c1a6302bee7c9c89/Lib/json/tool.py#L61
[1] https://github.com/python/cpython/blob/af08db7bac3087aac313d052c1a6302bee7c9c89/Lib/ast.py#L1510

----------
components: Library (Lib)
messages: 374269
nosy: alexandre.vassalotti, xtreak
priority: normal
severity: normal
status: open
title: pickle and pickletools cli interface doesn't close input and output file.
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41395>
_______________________________________

From report at bugs.python.org  Sat Jul 25 10:43:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2020 14:43:35 +0000
Subject: [issue41395] pickle and pickletools cli interface doesn't close input
 and output file.
In-Reply-To: <1595686330.63.0.838691465271.issue41395@roundup.psfhosted.org>
Message-ID: <1595688215.7.0.812684852534.issue41395@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41395>
_______________________________________

From report at bugs.python.org  Sat Jul 25 11:27:05 2020
From: report at bugs.python.org (Tomasz Pytel)
Date: Sat, 25 Jul 2020 15:27:05 +0000
Subject: [issue41396] pystate.c:_PyCrossInterpreterData_Release() does not
 clear py exception on error
Message-ID: <1595690825.61.0.00830808011082.issue41396@roundup.psfhosted.org>


New submission from Tomasz Pytel <tompytel at gmail.com>:

The call to _PyInterpreterState_LookUpID() may generate a Python exception but it is not explicitly cleared on error and no indicator is returned to signal failure. This can lead to a "a function returned a result with an error set" fatal error, and does in fact do so in a case I encountered in Modules/_xxsubinterpreters.c:channel_destroy().

----------
components: Interpreter Core
messages: 374270
nosy: Tomasz Pytel
priority: normal
severity: normal
status: open
title: pystate.c:_PyCrossInterpreterData_Release() does not clear py exception on error
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41396>
_______________________________________

From report at bugs.python.org  Sat Jul 25 11:32:38 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Jul 2020 15:32:38 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595691158.74.0.167591378014.issue41314@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 11:44:30 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 25 Jul 2020 15:44:30 +0000
Subject: [issue40816] Add missed AsyncContextDecorator to contextlib
In-Reply-To: <1590763993.17.0.319482222949.issue40816@roundup.psfhosted.org>
Message-ID: <1595691870.32.0.282396396761.issue40816@roundup.psfhosted.org>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40816>
_______________________________________

From report at bugs.python.org  Sat Jul 25 12:07:12 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 16:07:12 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595693232.55.0.91993596026.issue41314@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Waiting for someone to submit a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 13:21:42 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2020 17:21:42 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595697702.58.0.64634125784.issue41349@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I can somewhat reproduce the problem with both IDLE and tkinter.Tk() in 3.9b3 and an external monitor.

What I did:
- Start IDLE (or a shell running tkinter.Tk()
- Maximize window without changing monitor settings: OK
- Revert to regular window
- Rotate monitor 90 degrees in the Display settings (monitor itself not rotated)
- Maximize window again and revert back to regular size
- Revert changes to monitor settings

When I maximise the window with a rotated display the window grows to cover most of the display, but not all of it: There is a blank area between the menu bar and the top of the window. The height of that area is about that of the titlebar of the window. 


The window grows to the right size if I first rotate the screen and then start tkinter.Tk(). But then window won't go full-size when the screen is rotated back, some space is left between the righthand side of the window and the edge of the screen (again about the same amount of pixels as the height of the title bar).

Issues like this tend to be problems with the macOS port of Tk itself, I expect that to be the case in this instance as well. 


System:
- Python 3.9b3 (python.org installer)
- macOS 10.15.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:23:01 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 25 Jul 2020 18:23:01 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595701381.93.0.874520633118.issue41314@roundup.psfhosted.org>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
keywords: +patch
nosy: +YoSTEALTH
nosy_count: 5.0 -> 6.0
pull_requests: +20758
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/21616

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:30:34 2020
From: report at bugs.python.org (Lewis Ball)
Date: Sat, 25 Jul 2020 18:30:34 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595701834.13.0.397134416072.issue41388@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

So it looks like `pyparse.Parser.find_good_parse_start` is responsible for truncating the code to only look for the matching bracket in the current statement, which uses _synchre.

Testing it out, it sometimes will go to the most recent match of _synchre, but will sometimes go back to an even earlier match in the code, which is why something like
```
else
(
else)
```
manages to match without an issue. The `find_good_parse_start` will truncate at the first `else` in this case, instead at the second one.

Removing `else` from the _synchre regex did solve this problem for me though, as `find_good_parse_start` will then try to truncate even earlier when looking for the start of the statement, which will be before the opener. Although, I haven't checked what else would be affected by this change. I am not sure why this worked for me and did not work for you Terry.

Also, even with this fix it seems like 'find_good_parse_start` goes back further than it needs to. Fixing that may not change much, but would offer a slight performance increase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Sat Jul 25 15:00:49 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 25 Jul 2020 19:00:49 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595703649.05.0.303182956318.issue41314@roundup.psfhosted.org>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 15:17:47 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2020 19:17:47 +0000
Subject: [issue40456] Complete adding silent mode for py_compile
In-Reply-To: <1588285530.29.0.122281949999.issue40456@roundup.psfhosted.org>
Message-ID: <1595704667.39.0.0502561498677.issue40456@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

This is a duplicate of issue 38731. The inline patch in msg373791 is incorrect. I'll fix the error in maintenance releases by partially reverting commit 2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> bad input crashes py_compile library

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40456>
_______________________________________

From report at bugs.python.org  Sat Jul 25 15:58:56 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2020 19:58:56 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1595707136.33.0.297645693528.issue38731@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset daff39070e7ea71b0ba49d9150ac7a210a125682 by Gregory Schevchenko in branch 'master':
bpo-38731: Add --quiet option to py_compile CLI (GH-17134)
https://github.com/python/cpython/commit/daff39070e7ea71b0ba49d9150ac7a210a125682


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Sat Jul 25 16:22:11 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2020 20:22:11 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1595708531.24.0.256320382091.issue38731@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +20759
pull_request: https://github.com/python/cpython/pull/21617

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Sat Jul 25 16:43:52 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2020 20:43:52 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1595709832.58.0.740854841355.issue38731@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 2024d7aca100c3faa9c6730aba3de5f0528750be by Berker Peksag in branch '3.9':
bpo-38731: Fix NameError in command-line interface of py_compile (GH-21617)
https://github.com/python/cpython/commit/2024d7aca100c3faa9c6730aba3de5f0528750be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Sat Jul 25 16:44:03 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 20:44:03 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1595709843.51.0.288727282671.issue38731@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20760
pull_request: https://github.com/python/cpython/pull/21618

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:03:53 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2020 21:03:53 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1595711033.18.0.402431815701.issue38731@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 949cf93f8ee27c37650483458f0aa3e295011ef6 by Miss Islington (bot) in branch '3.8':
bpo-38731: Fix NameError in command-line interface of py_compile (GH-21617)
https://github.com/python/cpython/commit/949cf93f8ee27c37650483458f0aa3e295011ef6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:05:08 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2020 21:05:08 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1595711108.92.0.648528486873.issue38731@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:05:36 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:05:36 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595711136.32.0.0035403234033.issue18280@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Marking this as "easy". People are welcome to submit PRs that fix the wording in one or a small number of modules called out in Serhiy's list.

----------
keywords: +easy
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:11:10 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:11:10 +0000
Subject: [issue37082] Assignment expression symbol (walrus) not in built-in
 help()
In-Reply-To: <1559067983.32.0.880606504508.issue37082@roundup.psfhosted.org>
Message-ID: <1595711470.32.0.79165854393.issue37082@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We might get more help with this issue if the process of updating the help() output were better documented. I recently looked into what it would take to add "FSTRINGS" to the "topics" list, and it's quite complicated -- I only persevered after stepping through pydoc.help() using pdb. I wrote up a few tips in issue41045.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37082>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:22:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:22:55 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
In-Reply-To: <1595351360.26.0.0463175809492.issue41362@roundup.psfhosted.org>
Message-ID: <1595712175.02.0.538745473823.issue41362@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Sorry, I realize what's wrong here. When we switched to the new PEG parser (the "pegen" you saw mentioned in the warning) we switched to a new grammar file. You have to change Grammar/python.gram instead of Grammar/Grammar.

We couldn't get rid of the Grammar/Grammar file yet because it's mentioned in the docs; this is pending a better way of producing https://docs.python.org/3.10/reference/grammar.html.

I hope this has informed you sufficiently; I don't think there's a bug that needs to be fixed on our end.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:25:46 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:25:46 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595712346.82.0.593141519773.issue40939@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

There are some difficulties with removing Grammar/Grammar, since it is used to generate the full grammar in the reference docs (Doc/reference/grammar.rst). Producing a similar grammar from the PEG grammar is currently painful because our PEG grammar contains a number of "invalid_*" rules that just exist to be able to produce more useful error messages.

See https://github.com/we-like-parsers/cpython/issues/135.

The continued existence of Grammar/Grammar has confused at least one person, see issue41362.

Grepping for Grammar/Grammar in the docs, there are a few other occurrences:

library/token.rst:14:of the parse tree (terminal tokens).  Refer to the file :file:`Grammar/Grammar`
library/parser.rst:43::file:`Grammar/Grammar` in the standard Python distribution.  The parse trees
library/symbol.rst:15:names.  Refer to the file :file:`Grammar/Grammar` in the Python distribution for
reference/grammar.rst:7:.. literalinclude:: ../../Grammar/Grammar

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:43:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 21:43:01 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595713381.69.0.620295675756.issue41314@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0028c14073109595e7532ec00bb1e8bf39ecfb4d by YoSTEALTH in branch 'master':
bpo-41314: fixed annotations __future__ version (GH-21616)
https://github.com/python/cpython/commit/0028c14073109595e7532ec00bb1e8bf39ecfb4d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:43:09 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 21:43:09 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595713389.51.0.718645517297.issue41314@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20762
pull_request: https://github.com/python/cpython/pull/21621

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:43:02 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 21:43:02 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595713382.45.0.996100386219.issue41314@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20761
pull_request: https://github.com/python/cpython/pull/21620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:46:11 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:46:11 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595713571.1.0.756493555922.issue41314@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Never mind, Miss Islington failed to backport to 3.7, so let's forget about that.

----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:44:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:44:13 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595713453.68.0.00713680020345.issue41314@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@ned This will need your assistance to merge the 3.7 backport IIUC.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:57:06 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:57:06 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1595714226.92.0.168137821162.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This can be closed. It needs docs though; there's a separate issue for that (issue40814).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:57:53 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 25 Jul 2020 21:57:53 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595714273.28.0.0847634792267.issue41314@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

@gvanrossum I found couple of odd places where 4.0 is mentioned like https://docs.python.org/3/library/array.html for example, should a new issue be created? I am not sure how many more there are.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:58:08 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 21:58:08 +0000
Subject: [issue40814] Update typing module documentation based on PEP 585
In-Reply-To: <1590755313.42.0.558710518983.issue40814@roundup.psfhosted.org>
Message-ID: <1595714288.89.0.230698581652.issue40814@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Alternatively, we at least need a section of documentation for things like `list[int]` and `dict[str, float]`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40814>
_______________________________________

From report at bugs.python.org  Sat Jul 25 18:00:23 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 22:00:23 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595714423.65.0.301181538159.issue41314@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b99f770230e0db390aa80c5135b1053f3be48e19 by Miss Islington (bot) in branch '3.8':
bpo-41314: fixed annotations __future__ version (GH-21616)
https://github.com/python/cpython/commit/b99f770230e0db390aa80c5135b1053f3be48e19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 18:00:51 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 22:00:51 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595714451.15.0.625918768754.issue41314@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fdc91c2e6096f60ddb8b7f72fe7926ccbbf42800 by Miss Islington (bot) in branch '3.9':
bpo-41314: fixed annotations __future__ version (GH-21616)
https://github.com/python/cpython/commit/fdc91c2e6096f60ddb8b7f72fe7926ccbbf42800


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 18:08:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 22:08:37 +0000
Subject: [issue41370] PEP 585 and ForwardRef
In-Reply-To: <1595448974.26.0.905372860878.issue41370@roundup.psfhosted.org>
Message-ID: <1595714917.48.0.186525012002.issue41370@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Hm, recursive type aliases are an interesting issue. We may be able to do better there for 3.10, even if we can't fix it for 3.9 (or at least not for 3.9.0).

But in the meantime maybe you can come up with a PR that adds a note to the typing docs in 3.10 explaining that `list["int"]` will not be resolved to `list[int]`, even though it works for `List["int"]`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41370>
_______________________________________

From report at bugs.python.org  Sat Jul 25 18:12:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 22:12:13 +0000
Subject: [issue41314] PEP 563 and annotations __future__ mandatory version
In-Reply-To: <1594895664.43.0.284456467746.issue41314@roundup.psfhosted.org>
Message-ID: <1595715133.16.0.0550923782079.issue41314@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

In general, "4.0" means "never", and for some deprecations that seems totally appropriate. I wouldn't worry about it. I'm closing this issue now that all three PRs have been merged. Thanks for your contribution!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41314>
_______________________________________

From report at bugs.python.org  Sat Jul 25 18:21:07 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jul 2020 22:21:07 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_idle_not_going_full_screen_when_I_rotate_scree?=
 =?utf-8?q?n_90=C2=B0_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595715667.33.0.665268083036.issue41349@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The way to tell if _tkinter is involved or if this is purely tcl/tk issue would be for someone open a window directly with tcl/tk commands using either wish or maybe tkinter.tcl.  I don't know how.  I think that _tkinter involvement is maximize handling is sufficiently unlikely that I would close this as 3rd party.

----------
assignee: terry.reedy -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Sat Jul 25 18:43:12 2020
From: report at bugs.python.org (Bryan Hu)
Date: Sat, 25 Jul 2020 22:43:12 +0000
Subject: [issue32113] Strange behavior with await in a generator expression
In-Reply-To: <1511361761.52.0.213398074469.issue32113@psf.upfronthosting.co.za>
Message-ID: <1595716992.75.0.080697189793.issue32113@roundup.psfhosted.org>


Change by Bryan Hu <bryan.hu.cn at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32113>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:33:51 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 23:33:51 +0000
Subject: [issue39868] Stale Python Language Reference docs (no walrus).
In-Reply-To: <1583445248.34.0.0516528795686.issue39868@roundup.psfhosted.org>
Message-ID: <1595720031.62.0.860853536783.issue39868@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset f117cef25b5ffc4db9fbe373ddb65e14f59f0397 by Shankar Jha in branch 'master':
bpo-39868: Add documentation for Assignment Expressions (walrus, PEP 572) (#18851)
https://github.com/python/cpython/commit/f117cef25b5ffc4db9fbe373ddb65e14f59f0397


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39868>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:34:12 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 23:34:12 +0000
Subject: [issue39868] Stale Python Language Reference docs (no walrus).
In-Reply-To: <1583445248.34.0.0516528795686.issue39868@roundup.psfhosted.org>
Message-ID: <1595720052.35.0.888955856251.issue39868@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20763
pull_request: https://github.com/python/cpython/pull/21622

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39868>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:34:20 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 23:34:20 +0000
Subject: [issue39868] Stale Python Language Reference docs (no walrus).
In-Reply-To: <1583445248.34.0.0516528795686.issue39868@roundup.psfhosted.org>
Message-ID: <1595720060.41.0.244157858478.issue39868@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20764
pull_request: https://github.com/python/cpython/pull/21623

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39868>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:40:51 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 23:40:51 +0000
Subject: [issue39868] Stale Python Language Reference docs (no walrus).
In-Reply-To: <1583445248.34.0.0516528795686.issue39868@roundup.psfhosted.org>
Message-ID: <1595720451.22.0.9308426999.issue39868@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 616734b6c80e222f16249e9a9ce52588a0b611a7 by Miss Islington (bot) in branch '3.9':
bpo-39868: Add documentation for Assignment Expressions (walrus, PEP 572) (GH-18851)
https://github.com/python/cpython/commit/616734b6c80e222f16249e9a9ce52588a0b611a7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39868>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:41:23 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jul 2020 23:41:23 +0000
Subject: [issue39868] Stale Python Language Reference docs (no walrus).
In-Reply-To: <1583445248.34.0.0516528795686.issue39868@roundup.psfhosted.org>
Message-ID: <1595720483.99.0.495267003388.issue39868@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 755cb49429581679fc7b12905cb3d3ecf439032c by Miss Islington (bot) in branch '3.8':
bpo-39868: Add documentation for Assignment Expressions (walrus, PEP 572) (GH-18851)
https://github.com/python/cpython/commit/755cb49429581679fc7b12905cb3d3ecf439032c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39868>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:55:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Jul 2020 23:55:37 +0000
Subject: [issue39868] Stale Python Language Reference docs (no walrus).
In-Reply-To: <1583445248.34.0.0516528795686.issue39868@roundup.psfhosted.org>
Message-ID: <1595721337.24.0.607421816651.issue39868@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Congratulations SHANKAR JHA. Thank you for your contribution.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39868>
_______________________________________

From report at bugs.python.org  Sat Jul 25 20:05:23 2020
From: report at bugs.python.org (Lewis Ball)
Date: Sun, 26 Jul 2020 00:05:23 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595721923.56.0.705875685456.issue41388@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

Okay, on further examination `find_good_parse_start` first looks for a line ending with ':\n', and then looks to match _synchre on that line. If it can't find any line ending in ':\n' then it will just look for the first occurrence of something in _synchre to truncate on. If it can't find anything at that point, it just doesn't truncate and the whole code is checked for a bracket match.

So the reason that 
```
else
(
else)
```
works is because there is no `:` after the first else, and adding `:` will cause the matching to fail.

This seems reasonable, and I was probably too quick to say that the function goes back further than it needs to when looking to truncate.

It seems like then that `else` being removed from _synchre will fix this, and mean that the only time brackets aren't matched are when invalid code is typed, something like:
```
(
def)
```

I can put in a PR for this tomorrow (probably removing `yield` at the same time) if this sounds like the right fix.

P.S. Here is an example of the similar `yield` error that Terry alluded to:
```
def f():
    for i in range(10):
        (
        yield x)
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Sat Jul 25 21:39:05 2020
From: report at bugs.python.org (Constant Marks)
Date: Sun, 26 Jul 2020 01:39:05 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
In-Reply-To: <1595712175.02.0.538745473823.issue41362@roundup.psfhosted.org>
Message-ID: <CA+socgSg0W0gGs1=dLN6YcUr0Pch7bp04DZ9Sr94mxHJhiEoSQ@mail.gmail.com>


Constant Marks <crmarksv at gmail.com> added the comment:

Thanks. I will check it out when I get back in front of my computer.

On Sat, Jul 25, 2020 at 4:22 PM Guido van Rossum <report at bugs.python.org>
wrote:

>
> Guido van Rossum <guido at python.org> added the comment:
>
> Sorry, I realize what's wrong here. When we switched to the new PEG parser
> (the "pegen" you saw mentioned in the warning) we switched to a new grammar
> file. You have to change Grammar/python.gram instead of Grammar/Grammar.
>
> We couldn't get rid of the Grammar/Grammar file yet because it's mentioned
> in the docs; this is pending a better way of producing
> https://docs.python.org/3.10/reference/grammar.html.
>
> I hope this has informed you sufficiently; I don't think there's a bug
> that needs to be fixed on our end.
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41362>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Sat Jul 25 23:22:31 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 03:22:31 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595733751.77.0.0700040796106.issue40939@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +20765
pull_request: https://github.com/python/cpython/pull/21624

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Sun Jul 26 00:25:20 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 04:25:20 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1595737520.63.0.719124631628.issue37309@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b74e53607576ec92c0f319559b8bb1e34ed5c38b by Miss Islington (bot) in branch '3.9':
bpo-37309: NEWS for GH-41373 (GH-21612)
https://github.com/python/cpython/commit/b74e53607576ec92c0f319559b8bb1e34ed5c38b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Sun Jul 26 00:43:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jul 2020 04:43:53 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595738633.3.0.343910831514.issue41388@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As I at least hinted above, I would rather add the missing line starts than delete more.  I am quite sure that their absence degrades overall performance in some sense.  A much bigger match problem that this one is that ^0 always half fails when the cursor is not on the line with the closer.  See #21756, which already has a patch, though not one I was completely happy with last time I looked.

I cannot help but think that a proper solution might fix both issues.

I once wrote a fence matcher in C, initially for C, based on a deterministic finite state machine but with a push-down stack so it could match indefinite nesting.  I am thinking that I should try to rewrite in python and see if it will solve both issues.  Find good parse start is not really the right tool, because what we want to do with ^0 is to move both back and forward, find the first unmatched fence in each direction, and flash them, and add a beep if unmatched.  BOF and EOF (begin/end of file) are the backup fences.

Another possible solution might be to use a depleted _synchre for matching and an augmented one for any other use where that is better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Sun Jul 26 01:34:22 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 26 Jul 2020 05:34:22 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595741662.53.0.102857144808.issue41340@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

@fj92f3jj923f923 Would you update the PR to remove the strdup.c?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 03:21:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 07:21:45 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
In-Reply-To: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>
Message-ID: <1595748105.77.0.404162479024.issue41385@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b1a87300a06324c9fc7d6553906ed914489465aa by Serhiy Storchaka in branch 'master':
bpo-41385: Fix test_executable_without_cwd on Windows (GH-21608)
https://github.com/python/cpython/commit/b1a87300a06324c9fc7d6553906ed914489465aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Sun Jul 26 03:22:03 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 07:22:03 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
In-Reply-To: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>
Message-ID: <1595748123.19.0.584516377018.issue41385@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20767
pull_request: https://github.com/python/cpython/pull/21626

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Sun Jul 26 03:21:55 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 07:21:55 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
In-Reply-To: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>
Message-ID: <1595748115.58.0.963834412968.issue41385@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +20766
pull_request: https://github.com/python/cpython/pull/21625

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Sun Jul 26 03:22:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 07:22:38 +0000
Subject: [issue41373] IDLE: edit/save files created by Windows Explorer
In-Reply-To: <1595476036.59.0.577119776706.issue41373@roundup.psfhosted.org>
Message-ID: <1595748158.26.0.0395420111302.issue41373@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41373>
_______________________________________

From report at bugs.python.org  Sun Jul 26 03:38:55 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 07:38:55 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
In-Reply-To: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>
Message-ID: <1595749135.62.0.3018004528.issue41385@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 33cebe0b9a71da97046fc67c03062987c1049418 by Miss Islington (bot) in branch '3.8':
bpo-41385: Fix test_executable_without_cwd on Windows (GH-21608)
https://github.com/python/cpython/commit/33cebe0b9a71da97046fc67c03062987c1049418


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Sun Jul 26 03:38:55 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 07:38:55 +0000
Subject: [issue41385] test_executable_without_cwd fails on appx test run in
 Azure pipelines
In-Reply-To: <1595602250.31.0.334276668507.issue41385@roundup.psfhosted.org>
Message-ID: <1595749135.96.0.813221692712.issue41385@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8b7544cd024077615c62517f91ee74f50f40701d by Miss Islington (bot) in branch '3.9':
bpo-41385: Fix test_executable_without_cwd on Windows (GH-21608)
https://github.com/python/cpython/commit/8b7544cd024077615c62517f91ee74f50f40701d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41385>
_______________________________________

From report at bugs.python.org  Sun Jul 26 04:25:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 08:25:52 +0000
Subject: [issue41397] Restore default implementation of __ne__ in Counter
Message-ID: <1595751952.59.0.424974344046.issue41397@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently collections.Counter implements both __eq__ and __ne__ methods. The problem is that if you subclass Counter and override its __eq__ method you will need to implement also the __ne__ method. Usually you do not need to implement __ne__ because the implementation inherited from the object class does the right thing in most cases (unless you implement NumPy or symbolic expressions). Also, the Python implementation of Counter.__ne__ is a tiny bit slower than the C implementation of object.__ne__.

Counter.__ne__ was added because the implementation of __ne__ inherited from dict did not work correct for Counter. But we can just restore the default implementation:

    __ne__ = object.__ne__

Of all Python classes in the stdlib which implement __eq__ only Counter, WeakRef and some mock classes implement also __ne__. In case of Counter I think it is not necessary.

----------
components: Library (Lib)
messages: 374306
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Restore default implementation of __ne__ in Counter
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41397>
_______________________________________

From report at bugs.python.org  Sun Jul 26 04:30:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 08:30:01 +0000
Subject: [issue41397] Restore default implementation of __ne__ in Counter
In-Reply-To: <1595751952.59.0.424974344046.issue41397@roundup.psfhosted.org>
Message-ID: <1595752201.28.0.403342322158.issue41397@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20768
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21627

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41397>
_______________________________________

From report at bugs.python.org  Sun Jul 26 05:58:24 2020
From: report at bugs.python.org (Magnus Johnsson)
Date: Sun, 26 Jul 2020 09:58:24 +0000
Subject: [issue41398] cgi module, parse_multipart fails
Message-ID: <1595757503.98.0.375306375596.issue41398@roundup.psfhosted.org>


New submission from Magnus Johnsson <magnusjjj at gmail.com>:

When using the cgi module, parse_multipart fails with the supplied file with the error:

Invalid boundary in multipart form: b''

A sample program that demonstrates the error:
import cgi
f = open("60_Request.txt", "r")
print(cgi.parse_multipart(f, {'boundary': b'BgTzK0jM20UH01naJdsmAWUj7sqqeoikGZvh3mo9', 'CONTENT-LENGTH': 3992}))

This affects for instance Twisted, and all its dependencies.

----------
files: 60_Request.txt
messages: 374307
nosy: Magnus Johnsson
priority: normal
severity: normal
status: open
title: cgi module, parse_multipart fails
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49340/60_Request.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41398>
_______________________________________

From report at bugs.python.org  Sun Jul 26 06:17:57 2020
From: report at bugs.python.org (wyz23x2)
Date: Sun, 26 Jul 2020 10:17:57 +0000
Subject: [issue41399] Add stacklevel support for exceptions
Message-ID: <1595758677.39.0.962051820395.issue41399@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Now warnings.warn supports a stacklevel parameter. But many users want exceptions to support it too.
Related:
https://stackoverflow.com/questions/34175111/raise-an-exception-from-a-higher-level-a-la-warnings

----------
components: Interpreter Core
messages: 374308
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Add stacklevel support for exceptions
type: enhancement
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41399>
_______________________________________

From report at bugs.python.org  Sun Jul 26 06:18:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 10:18:46 +0000
Subject: [issue41400] Remove references to nonexisting __ne__ methods
Message-ID: <1595758726.41.0.0930061303675.issue41400@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There is the documentation for method __ne__ implementations in classes Set, Mapping, Header, Charset, Binary, but all these implementations are removed now and the default implementation of object.__ne__ is used instead.

----------
assignee: docs at python
components: Documentation
messages: 374309
nosy: barry, docs at python, maxking, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Remove references to nonexisting __ne__ methods
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________

From report at bugs.python.org  Sun Jul 26 06:19:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 10:19:52 +0000
Subject: [issue41400] Remove references to nonexisting __ne__ methods
In-Reply-To: <1595758726.41.0.0930061303675.issue41400@roundup.psfhosted.org>
Message-ID: <1595758792.9.0.175013892486.issue41400@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20769
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21628

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________

From report at bugs.python.org  Sun Jul 26 06:23:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 10:23:51 +0000
Subject: [issue41399] Add stacklevel support for exceptions
In-Reply-To: <1595758677.39.0.962051820395.issue41399@roundup.psfhosted.org>
Message-ID: <1595759031.96.0.31647934651.issue41399@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

warnings.warn(), the function which emits warnings, has the stacklevel parameter. But how do you provide stacklevel for exceptions?

See also bpo-39725.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41399>
_______________________________________

From report at bugs.python.org  Sun Jul 26 07:55:16 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 26 Jul 2020 11:55:16 +0000
Subject: [issue41398] cgi module, parse_multipart fails
In-Reply-To: <1595757503.98.0.375306375596.issue41398@roundup.psfhosted.org>
Message-ID: <1595764516.79.0.426506311446.issue41398@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +ethan.furman
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41398>
_______________________________________

From report at bugs.python.org  Sun Jul 26 09:32:40 2020
From: report at bugs.python.org (Iman Sharafaldin)
Date: Sun, 26 Jul 2020 13:32:40 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595770360.39.0.599318974928.issue41288@roundup.psfhosted.org>


Iman Sharafaldin <iman.sharafodin at gmail.com> added the comment:

@serhiy.storchaka Hi Serhiy, do you count this issue as a security issue? Also, I didn't see that in the latest changelog. Is it now patched on the latest version?

https://docs.python.org/release/3.8.5/whatsnew/changelog.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:07:03 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 26 Jul 2020 14:07:03 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
Message-ID: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

issue41069 introduces tests for paths/files containing non-ascii characters.

On AIX - since the merge of PR21035 and PR21156 - the bots have been broken, i.e., returning test failed.

commit 700cfa8c90a90016638bac13c4efd03786b2b2a0
Author: Serhiy Storchaka <storchaka at gmail.com>
Date:   Thu Jun 25 17:56:31 2020 +0300

    bpo-41069: Make TESTFN and the CWD for tests containing non-ascii characters. (GH-21035)

commit f925407a19eeb9bf5f7640143979638adce2c677
Author: Serhiy Storchaka <storchaka at gmail.com>
Date:   Thu Jun 25 20:39:12 2020 +0300

    [3.9] bpo-41069: Make TESTFN and the CWD for tests containing non-ascii characters. (GH-21035). (GH-21156)

    (cherry picked from commit 700cfa8c90a90016638bac13c4efd03786b2b2a0)

++++++++

Sadly, I cannot determine - exactly - where it is going wrong as the verbose results ends (says SUCCESS, but there is an ENV change, so bot says FAILED) as:

----------------------------------------------------------------------

Ran 614 tests in 59.122s

OK (skipped=8)
Warning -- files was modified by test_io
  Before: []
  After:  ['@test_23134518_tmp?']
test_io failed (env changed) in 59.7 sec

== Tests result: SUCCESS ==

1 test altered the execution environment:
    test_io

Total duration: 59.8 sec

----------
components: IO, Tests
messages: 374312
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Using non-ascii that require UTF-8 breaks AIX testing
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:14:50 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 26 Jul 2020 14:14:50 +0000
Subject: [issue41090] Support for "Universal 2" binary builds
In-Reply-To: <1592913185.49.0.15166324196.issue41090@roundup.psfhosted.org>
Message-ID: <1595772890.3.0.855782336919.issue41090@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

We're tracking macOS 11 and arm64 support in #41100

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Build failure on macOS 11 (beta)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41090>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:15:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 26 Jul 2020 14:15:16 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595772916.4.0.810924241233.issue41401@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:19:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 14:19:49 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595773189.08.0.0426520500882.issue41288@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think it is a security issue. The crash cannot be triggered by the user input unless you accept the pickle data from untrusted sources, but in that case you are in large danger, because you allow executing arbitrary code.

The changes in this issue just help to debug in some cases when you play with pickle format. In any case thank you for your report.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:31:40 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 26 Jul 2020 14:31:40 +0000
Subject: [issue41100] Build failure on macOS 11 (beta)
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1595773900.84.0.78545938359.issue41100@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

PR21564 is my attempt to merge all changes needed to support macOS 11 and arm64.  To be honest I had lost track of what's needed.

With this the patch the tests pass on my DTK system. 

TODO:
- Verify builds on older macOS versions
- Maybe: support building using non-system libffi on macOS


PR 21583 is a separate attempt at doing the code changes that are needed to build with the latest SDK and deploy on macOS 10.9.  This patch is still in a fairly rough state, and needs more testing (I haven't done any testing on older platforms yet)

TODO:
- Test on macOS 10.9
- Tweak the build-installer script and possibly _osx_support.py: the minimal deployment target for arm64 should be macOS 11.0.
- Tweak the build-installer script to build an optimised version

TDB:
- Keep this as two separate PRs or merge them? 
  The latter makes testing easier, but review harder

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:32:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 14:32:02 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595773922.21.0.333650602527.issue41401@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report (and for all other heroic work for maintaining AIX). Breaking only one test on AIX looks like a good news.

Do you able to run tests manually? Could you please run the following command?

    ./python -m test --list-cases -uall test_io | xargs -n 1 ./python -m test -vuall test_io -m

It may help to determine what exactly the test was broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:01:55 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Sun, 26 Jul 2020 15:01:55 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595775715.49.0.540661570152.issue41380@roundup.psfhosted.org>


Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com> added the comment:

@gvanrossum, Can you merge my pull requests?

----------
components:  -Library (Lib)
nosy:  -epaine, gregorlingl, terry.reedy, willingc
type: enhancement -> 
versions:  -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:06:46 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 26 Jul 2020 15:06:46 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595776006.03.0.540734747336.issue41341@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Given the previous behavior was clearly a bug and after looking at the PR, I think it should go into 3.9.0rc1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:08:43 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 15:08:43 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595776123.33.0.409304254541.issue41341@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +20770
pull_request: https://github.com/python/cpython/pull/21629

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:11:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 15:11:17 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595776277.33.0.763948834539.issue41340@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

There?s probably also something in configure.in that can switch this on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:12:33 2020
From: report at bugs.python.org (Iman Sharafaldin)
Date: Sun, 26 Jul 2020 15:12:33 +0000
Subject: [issue41288] Pickle crashes unpickling invalid NEWOBJ_EX opcode
In-Reply-To: <1594589769.15.0.967548182299.issue41288@roundup.psfhosted.org>
Message-ID: <1595776353.09.0.795790036033.issue41288@roundup.psfhosted.org>


Iman Sharafaldin <iman.sharafodin at gmail.com> added the comment:

Thank you for patching that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41288>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:12:39 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 15:12:39 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1595776359.61.0.720579342037.issue41182@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20771
pull_request: https://github.com/python/cpython/pull/21630

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:13:30 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 26 Jul 2020 15:13:30 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1595776410.5.0.965364637856.issue41182@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

This is a bit of a risky change looking at the PR but since it's a bugfix, we should have it for 3.9.0rc1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:15:31 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 26 Jul 2020 15:15:31 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595776531.16.0.133568243697.issue41380@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Ehsonjon, please do not remove people from the nosy list.

----------
components: +Library (Lib)
nosy: +SilentGhost, epaine, gregorlingl, terry.reedy, willingc
type:  -> enhancement
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:19:57 2020
From: report at bugs.python.org (=?utf-8?q?=C5=9Eahin_Kureta?=)
Date: Sun, 26 Jul 2020 15:19:57 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1595776797.75.0.0520833724076.issue34723@roundup.psfhosted.org>


?ahin Kureta <skureta at gmail.com> added the comment:

I know it is not finalized and released yet but are you going to implement Version 14.0.0 of the Unicode Standard? It finally solves the issue of Turkish lower/upper case 'I' and 'i'.

[Here is the document](https://www.unicode.org/Public/14.0.0/ucd/NamesList-14.0.0d1.txt)

> 0049	LATIN CAPITAL LETTER I
	* Turkish and Azerbaijani use 0131 for lowercase

> 0069	LATIN SMALL LETTER I
	* Turkish and Azerbaijani use 0130 for uppercase

----------
nosy: +?ahin Kureta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:22:00 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 15:22:00 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595776920.02.0.470746680653.issue41340@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:31:27 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 15:31:27 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595777487.66.0.883739245266.issue41341@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 41d1c04f73185c1238680142aa1a81f54f2bf4a4 by Miss Islington (bot) in branch '3.9':
bpo-41341: Recursive evaluation of ForwardRef in get_type_hints (GH-21553)
https://github.com/python/cpython/commit/41d1c04f73185c1238680142aa1a81f54f2bf4a4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:32:28 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jul 2020 15:32:28 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1595777548.62.0.491489177771.issue41182@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6e4975a1c79d8433d9d5b50ff1c655b5b5a2acd2 by Miss Islington (bot) in branch '3.9':
bpo-41182 selector: use DefaultSelector based upon implementation (GH-21257)
https://github.com/python/cpython/commit/6e4975a1c79d8433d9d5b50ff1c655b5b5a2acd2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:33:20 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 15:33:20 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595777600.51.0.736079096785.issue41380@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:35:01 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 26 Jul 2020 15:35:01 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595777701.25.0.892082807553.issue18280@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I am taking a look at these, and I am sure there is a PEP I am unaware of - atm - so, a quick question.

Is the double space at the end of a sentence 'required' by the rst processing, or is this also a 'personal' writing style in some of the documents (i.e., is replacing them with a single ' ', or otherwise, a new line ('\n') an error.

iirc - new paragraphs are indicated by two new-lines.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:35:12 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 15:35:12 +0000
Subject: [issue41341] Recursive evaluation of ForwardRef (and PEP 563)
In-Reply-To: <1595158107.48.0.291386757001.issue41341@roundup.psfhosted.org>
Message-ID: <1595777712.22.0.335227553199.issue41341@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thank you Joseph Perez! Looking forward to more of your contributions.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41341>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:37:03 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 15:37:03 +0000
Subject: [issue41182] DefaultSelector fails to detect selector on VMware ESXi
In-Reply-To: <1593601699.76.0.361945783635.issue41182@roundup.psfhosted.org>
Message-ID: <1595777823.91.0.914770023104.issue41182@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thank you Abhijeet! Looking forward to more of your contributions.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41182>
_______________________________________

From report at bugs.python.org  Sun Jul 26 12:00:39 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 26 Jul 2020 16:00:39 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595779239.08.0.353561814802.issue41380@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy:  -SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Sun Jul 26 12:03:53 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 26 Jul 2020 16:03:53 +0000
Subject: [issue41394] Document '_' in interpreter in shell tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595779433.18.0.592422044626.issue41394@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>I haven't checked to see what's documented. I'm sure we'd accept a patch that improves the documentation if it's lacking.
+1

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Sun Jul 26 12:39:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 16:39:28 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595781568.26.0.451779203455.issue18280@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think they are not required, but recommended.

>From https://www.python.org/dev/peps/pep-0008/#comments:

   You should use two spaces after a sentence-ending period in multi- sentence comments, except after the final sentence.

>From https://www.python.org/dev/peps/pep-0012/#general:

   You must adhere to the Emacs convention of adding two spaces at the end of every sentence.

AFAIK in English typography the space after a sentence-ending period is longer than spaces between words. In other European typographies they have the same width.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:01:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 17:01:41 +0000
Subject: [issue41400] Remove references to nonexisting __ne__ methods
In-Reply-To: <1595758726.41.0.0930061303675.issue41400@roundup.psfhosted.org>
Message-ID: <1595782901.62.0.296590233445.issue41400@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This will make the docs confusing and create an uncertainty for a user: if they define __eq__, do they, can they, or should they define __ne__.  

Also, it feels weird to have lists of five rich comparison methods rather than all six.

Tthe current docs better communicate which methods you need to supply and which methods get given to you for free.   Note, there is a dependency.  The object.__ne__ method depends on __eq__, so you don't get a useful __ne__ until and __eq__ is defined.  The meaning of __ne__ does in fact get changed by these classes.

So, while this doc edit is pedantically correct, it makes the documentation less useable than before.  I vote for leaving it as-is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:03:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 17:03:50 +0000
Subject: [issue41400] Remove references to nonexisting __ne__ methods
In-Reply-To: <1595758726.41.0.0930061303675.issue41400@roundup.psfhosted.org>
Message-ID: <1595783030.36.0.0209271734101.issue41400@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

s/pedantic/formally but not helpfully/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:14:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 17:14:45 +0000
Subject: [issue41397] Restore default implementation of __ne__ in Counter
In-Reply-To: <1595751952.59.0.424974344046.issue41397@roundup.psfhosted.org>
Message-ID: <1595783685.04.0.922745467238.issue41397@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The problem is that if you subclass Counter and override 
> its __eq__ method you will need to implement also the
> __ne__ method. 

I don't think that is true.  The current code for __ne__ calls "==" and inverts the result.

Also, the docstring for the current __ne__ code is useful because it documents the effect of missing counts.  That information would be lost with the PR.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41397>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:19:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 17:19:41 +0000
Subject: [issue41400] Remove references to nonexisting __ne__ methods
In-Reply-To: <1595758726.41.0.0930061303675.issue41400@roundup.psfhosted.org>
Message-ID: <1595783981.31.0.648024937829.issue41400@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is it good to provide incorrect information in the documentation? It is a matter of correctness, not style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:50:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 17:50:51 +0000
Subject: [issue41383] Provide a limit arguments for __repr__
In-Reply-To: <1595599493.43.0.939554432548.issue41383@roundup.psfhosted.org>
Message-ID: <1595785851.7.0.676631393809.issue41383@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I suggest taking this to Python ideas.  While there is a legitimate concern about large objects in a Variable View, the idea impacts long-standing core APIs.  Accordingly, it needs to be thought through, become better specified, and be evaluated against alternatives.  If the language impact is pervasive, it would likely need a PEP as well.

Some questions immediately come to mind:

* Would the existing standard and third party libraries need to recode every __repr__ or __str__ implementation for every container that has ever been written?  Would that include C code as well?

* It there something this limit parameter could do that couldn't already be achieved with __format__()?

* Should limits be a responsibility of individual classes or it is a debugger responsibility?  On the one hand, it is hard to see how a debugger could implement this without blind truncation; on the other hand, I don't think other languages make a similar inversion of responsibility.

* How would the parameter be accessed via the !r and !s codes in f-strings?

* How easy or hard would this be to implement for typical classes, lists for example?

* What is meant by "max number of symbols we want to evaluate"?  Would the repr for ['x'*1_000_000] count as one symbol or as one million?

* For tree-like structures (JSON for example), does a symbol limit make sense?  Wouldn't you want a depth limit instead.

* Would some variant of "..." be added to indicate that limits were applied and to prevent someone for accidentally running eval() on the output?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41383>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:51:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 17:51:07 +0000
Subject: [issue41383] Provide a limit arguments for __repr__
In-Reply-To: <1595599493.43.0.939554432548.issue41383@roundup.psfhosted.org>
Message-ID: <1595785867.41.0.46599508867.issue41383@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41383>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:51:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jul 2020 17:51:04 +0000
Subject: [issue41397] Restore default implementation of __ne__ in Counter
In-Reply-To: <1595751952.59.0.424974344046.issue41397@roundup.psfhosted.org>
Message-ID: <1595785864.68.0.222998363371.issue41397@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The current code returns NotImplemented for non-Counter. If we want to implement equality comparison with other class we have to override __ne__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41397>
_______________________________________

From report at bugs.python.org  Sun Jul 26 13:59:16 2020
From: report at bugs.python.org (Johannes Reiff)
Date: Sun, 26 Jul 2020 17:59:16 +0000
Subject: [issue41402] email: ContentManager.set_content calls nonexistent
 method encode() on bytes
Message-ID: <1595786356.19.0.0772009953039.issue41402@roundup.psfhosted.org>


New submission from Johannes Reiff <mail at jreiff.de>:

If assigning binary content to an EmailMessage via set_content(), the function email.contentmanager.set_bytes_content() is called. This function fails when choosing the 7bit transfer encoding because of a call to data.decode('ascii').

----------
components: email
messages: 374337
nosy: Johannes Reiff, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email: ContentManager.set_content calls nonexistent method encode() on bytes
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41402>
_______________________________________

From report at bugs.python.org  Sun Jul 26 14:12:12 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jul 2020 18:12:12 +0000
Subject: [issue41402] email: ContentManager.set_content calls nonexistent
 method encode() on bytes
In-Reply-To: <1595786356.19.0.0772009953039.issue41402@roundup.psfhosted.org>
Message-ID: <1595787132.75.0.905498573753.issue41402@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +20772
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21631

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41402>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:14:58 2020
From: report at bugs.python.org (Howard A. Landman)
Date: Sun, 26 Jul 2020 19:14:58 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595790898.38.0.657972312692.issue41335@roundup.psfhosted.org>


Howard A. Landman <howard at riverrock.org> added the comment:

After a quick glance at the source code for the spidev library, I think it is unlikely but not impossible to be the home for the bug. It does do malloc() and free(), but only for data that is greater than 256 bytes. Short tx and rx data is kept in static local buffers. Also, these calls do not match the partial stack trace I got. There is a small amount of allocating and deallocating Python objects, however, including calls to PyList_New(), PyList_SET_ITEM(), and Py_TYPE(self)->tp_free((PyObject *)self), so it's possible that the bug is buried under one of those.

----------
nosy:  -christian.heimes, stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:15:44 2020
From: report at bugs.python.org (webisteme)
Date: Sun, 26 Jul 2020 19:15:44 +0000
Subject: [issue41403] Uncaught AttributeError in unittest.mock._get_target
Message-ID: <1595790944.09.0.556229072962.issue41403@roundup.psfhosted.org>


New submission from webisteme <egothill at gmail.com>:

When calling `mock.patch` incorrectly, as in the following example, an uncaught error is thrown:

```shell
>>> from unittest import mock
>>> class Foo:
...     pass
... 
>>> mock.patch(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/mock.py", line 1624, in patch
    getter, attribute = _get_target(target)
  File "/usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/mock.py", line 1469, in _get_target
    target, attribute = target.rsplit('.', 1)
AttributeError: 'Foo' object has no attribute 'rsplit'
```
This can happen when confusing `mock.patch` with `mock.patch.object`. However, the uncaught error is not informative, as it does not indicate that the wrong type of object was passed to `mock.patch`.

----------
components: Library (Lib)
messages: 374339
nosy: webisteme
priority: normal
severity: normal
status: open
title: Uncaught AttributeError in unittest.mock._get_target
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41403>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:27:03 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 19:27:03 +0000
Subject: [issue41397] Restore default implementation of __ne__ in Counter
In-Reply-To: <1595751952.59.0.424974344046.issue41397@roundup.psfhosted.org>
Message-ID: <1595791623.07.0.485628357585.issue41397@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The current code returns NotImplemented for non-Counter.
> If we want to implement equality comparison with other 
> class we have to override __ne__.

I'm fine with that.  It is not an undue burden and it provides a nudge to be explicit and intentional about the decision.

Setting __ne__ = object.__ne__ is a neat trick, but it is surprising given
Counter's __mro__ and it loses the helpful docstring describing the effect of zero counts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41397>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:51:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jul 2020 19:51:59 +0000
Subject: [issue41400] Remove references to nonexisting __ne__ methods
In-Reply-To: <1595758726.41.0.0930061303675.issue41400@roundup.psfhosted.org>
Message-ID: <1595793119.73.0.716587398725.issue41400@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>From a user point of view, your edit makes it look like they have to supply __ne__() if they want support for the != operator.  The user would have to know the subtle details of the language to know this is not the case.  In documentation, more so than in code, explicit is better than implicit.

The tables that we have now do a good job of communicating, "if you supply these methods, then these other methods follow automatically".  It matters very little where those methods were defined in the __mro__.  In Python 2.7, collections.Set used to explicitly define __ne__ and now it just inherits it from object, but that is close to being just an implementation detail.  From a user point of view, it is the same.

It would fine to add a technical implementation note somewhere, perhaps as a footnote to the "Mixin Methods" column.  But mostly, the documentation is more useful and clear as it stands now.  In my professional life, I teach engineers directly from these tables, so I have extensive experience with the user's point of view on these particular docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:12:19 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jul 2020 20:12:19 +0000
Subject: [issue41404] IDLE: test iomenu
Message-ID: <1595794339.44.0.389957783464.issue41404@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Test parts of iomenu changed by #41158 and fixed by #41300 and #41373.

----------
assignee: terry.reedy
components: IDLE
messages: 374342
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: test iomenu
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41404>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:14:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jul 2020 20:14:51 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_Tk_window_not_going_full_screen_on_90=C2=B0_ro?=
 =?utf-8?q?tated__screen_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595794491.16.0.205973732026.issue41349@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +Tkinter
title: idle not going full screen when I rotate screen 90? on mac -> Tk window not going full screen on 90? rotated  screen on mac

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:56:14 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 26 Jul 2020 20:56:14 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595796974.08.0.28542353629.issue41401@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Neat! extra arguments!!

The warnings - extracted:

== CPython 3.10.0a0 (heads/master-dirty:b1a8730, Jul 26 2020, 14:00:34) [GCC 7.2.0]
== AIX-2-00F9C1964C00-powerpc-32bit big-endian
== cwd: /home/aixtools/cpython/cpython-master/build/test_python_27984450?
== CPU count: 32
== encodings: locale=ISO8859-1, FS=iso8859-1
0:00:00 Run tests sequentially
0:00:00 [1/1] test_io
test_fspath_support (test.test_io.CIOTest) ... ok

----------------------------------------------------------------------

Ran 1 test in 0.026s

OK
Warning -- files was modified by test_io
  Before: []
  After:  ['@test_27984450_tmp?']
test_io failed (env changed)

+++++
== CPython 3.10.0a0 (heads/master-dirty:b1a8730, Jul 26 2020, 14:00:34) [GCC 7.2.0]
== AIX-2-00F9C1964C00-powerpc-32bit big-endian
== cwd: /home/aixtools/cpython/cpython-master/build/test_python_28246552?
== CPU count: 32
== encodings: locale=ISO8859-1, FS=iso8859-1
0:00:00 Run tests sequentially
0:00:00 [1/1] test_io
test_fspath_support (test.test_io.PyIOTest) ... ok

----------------------------------------------------------------------

Ran 1 test in 0.026s

OK
Warning -- files was modified by test_io
  Before: []
  After:  ['@test_28246552_tmp?']
test_io failed (env changed)

== Tests result: SUCCESS ==

1 test altered the execution environment:
    test_io

++++

== CPython 3.10.0a0 (heads/master-dirty:b1a8730, Jul 26 2020, 14:00:34) [GCC 7.2.0]
== AIX-2-00F9C1964C00-powerpc-32bit big-endian
== cwd: /home/aixtools/cpython/cpython-master/build/test_python_33620404?
== CPU count: 32
== encodings: locale=ISO8859-1, FS=iso8859-1
0:00:00 Run tests sequentially
0:00:00 [1/1] test_io
test_reader_writer_close_error_on_close (test.test_io.CBufferedRWPairTest) ... ok

----------------------------------------------------------------------

Ran 1 test in 0.001s

OK
Warning -- Unraisable exception
Exception ignored in: <_io.BufferedRWPair object at 0x30689750>
Traceback (most recent call last):
  File "/home/aixtools/cpython/cpython-master/Lib/test/support/__init__.py", line 613, in gc_collect
    gc.collect()
ValueError: flush of closed file
Warning -- Unraisable exception
Exception ignored in: <_io.BufferedWriter>
Traceback (most recent call last):
  File "/home/aixtools/cpython/cpython-master/Lib/test/support/__init__.py", line 613, in gc_collect
    gc.collect()
ValueError: flush of closed file
test_io failed (env changed)

== Tests result: SUCCESS ==

1 test altered the execution environment:
    test_io

Hope this helps!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Sun Jul 26 17:11:06 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Sun, 26 Jul 2020 21:11:06 +0000
Subject: [issue41405] python 3.9.0b5 test
Message-ID: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

>>> /opt/python/3.9.0/bin/python3 -m test -uall
== CPython 3.9.0b5 (default, Jul 22 2020, 13:13:23) [GCC 10.1.0]
== Linux-5.8.0-1-MANJARO-x86_64-with-glibc2.31 little-endian
== cwd: /tmp/test_python_39605?
== CPU count: 16
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.24 Run tests sequentially
0:00:00 load avg: 1.24 [  1/425] test_grammar
0:00:00 load avg: 1.24 [  2/425] test_opcodes
0:00:00 load avg: 1.24 [  3/425] test_dict
0:00:00 load avg: 1.24 [  4/425] test_builtin
0:00:00 load avg: 1.24 [  5/425] test_exceptions
0:00:02 load avg: 1.22 [  6/425] test_types
0:00:02 load avg: 1.22 [  7/425] test_unittest
0:00:05 load avg: 1.22 [  8/425] test_doctest
0:00:06 load avg: 1.20 [  9/425] test_doctest2
0:00:07 load avg: 1.20 [ 10/425] test_support
0:00:09 load avg: 1.20 [ 11/425] test___all__
0:00:11 load avg: 1.20 [ 12/425] test___future__
0:00:11 load avg: 1.27 [ 13/425] test__locale
0:00:11 load avg: 1.27 [ 14/425] test__opcode
0:00:12 load avg: 1.27 [ 15/425] test__osx_support
0:00:12 load avg: 1.27 [ 16/425] test__xxsubinterpreters
0:00:13 load avg: 1.27 [ 17/425] test_abc
0:00:14 load avg: 1.27 [ 18/425] test_abstract_numbers
0:00:14 load avg: 1.27 [ 19/425] test_aifc
0:00:15 load avg: 1.27 [ 20/425] test_argparse
0:00:18 load avg: 1.24 [ 21/425] test_array
0:00:21 load avg: 1.22 [ 22/425] test_asdl_parser
test_asdl_parser skipped -- test irrelevant for an installed Python
0:00:21 load avg: 1.22 [ 23/425] test_ast -- test_asdl_parser skipped
0:00:24 load avg: 1.22 [ 24/425] test_asyncgen
0:00:25 load avg: 1.22 [ 25/425] test_asynchat
0:00:27 load avg: 1.13 [ 26/425] test_asyncio
0:02:10 load avg: 1.39 [ 27/425] test_asyncore -- test_asyncio passed in 1 min 43 sec
0:02:12 load avg: 1.28 [ 28/425] test_atexit
0:02:12 load avg: 1.28 [ 29/425] test_audioop
0:02:13 load avg: 1.28 [ 30/425] test_audit
0:02:14 load avg: 1.28 [ 31/425] test_augassign
0:02:15 load avg: 1.28 [ 32/425] test_base64
0:02:15 load avg: 1.28 [ 33/425] test_baseexception
0:02:15 load avg: 1.28 [ 34/425] test_bdb
0:02:16 load avg: 1.28 [ 35/425] test_bigaddrspace
0:02:16 load avg: 1.26 [ 36/425] test_bigmem
0:02:17 load avg: 1.26 [ 37/425] test_binascii
0:02:17 load avg: 1.26 [ 38/425] test_binhex
0:02:17 load avg: 1.26 [ 39/425] test_binop
0:02:18 load avg: 1.26 [ 40/425] test_bisect
0:02:18 load avg: 1.26 [ 41/425] test_bool
0:02:18 load avg: 1.26 [ 42/425] test_buffer
0:02:29 load avg: 1.30 [ 43/425] test_bufio
0:02:30 load avg: 1.30 [ 44/425] test_bytes
0:02:32 load avg: 1.35 [ 45/425] test_bz2
0:02:37 load avg: 1.33 [ 46/425] test_c_locale_coercion
0:02:40 load avg: 1.33 [ 47/425] test_calendar
0:02:44 load avg: 1.38 [ 48/425] test_call
0:02:44 load avg: 1.38 [ 49/425] test_capi
0:03:07 load avg: 1.23 [ 50/425] test_cgi
0:03:08 load avg: 1.23 [ 51/425] test_cgitb
0:03:08 load avg: 1.23 [ 52/425] test_charmapcodec
0:03:09 load avg: 1.23 [ 53/425] test_check_c_globals
test_check_c_globals skipped -- c-analyzer directory could not be found
0:03:09 load avg: 1.23 [ 54/425] test_class -- test_check_c_globals skipped
0:03:09 load avg: 1.23 [ 55/425] test_clinic
test_clinic skipped -- clinic directory could not be found
0:03:10 load avg: 1.23 [ 56/425] test_cmath -- test_clinic skipped
0:03:10 load avg: 1.23 [ 57/425] test_cmd
0:03:10 load avg: 1.23 [ 58/425] test_cmd_line
0:03:14 load avg: 1.21 [ 59/425] test_cmd_line_script
0:03:18 load avg: 1.27 [ 60/425] test_code
0:03:19 load avg: 1.27 [ 61/425] test_code_module
0:03:19 load avg: 1.27 [ 62/425] test_codeccallbacks
0:03:19 load avg: 1.27 [ 63/425] test_codecencodings_cn
0:03:20 load avg: 1.27 [ 64/425] test_codecencodings_hk
0:03:20 load avg: 1.27 [ 65/425] test_codecencodings_iso2022
0:03:21 load avg: 1.25 [ 66/425] test_codecencodings_jp
0:03:22 load avg: 1.25 [ 67/425] test_codecencodings_kr
0:03:23 load avg: 1.25 [ 68/425] test_codecencodings_tw
0:03:23 load avg: 1.25 [ 69/425] test_codecmaps_cn
0:03:27 load avg: 1.23 [ 70/425] test_codecmaps_hk
0:03:28 load avg: 1.23 [ 71/425] test_codecmaps_jp
0:03:33 load avg: 1.13 [ 72/425] test_codecmaps_kr
0:03:37 load avg: 1.12 [ 73/425] test_codecmaps_tw
0:03:40 load avg: 1.12 [ 74/425] test_codecs
0:03:42 load avg: 1.83 [ 75/425] test_codeop
0:03:42 load avg: 1.83 [ 76/425] test_collections
0:03:43 load avg: 1.83 [ 77/425] test_colorsys
0:03:44 load avg: 1.83 [ 78/425] test_compare
0:03:44 load avg: 1.83 [ 79/425] test_compile
0:03:47 load avg: 1.85 [ 80/425] test_compileall
0:04:00 load avg: 1.71 [ 81/425] test_complex
0:04:01 load avg: 1.71 [ 82/425] test_concurrent_futures
0:06:35 load avg: 1.28 [ 83/425] test_configparser -- test_concurrent_futures passed in 2 min 34 sec
0:06:36 load avg: 1.26 [ 84/425] test_contains
0:06:37 load avg: 1.26 [ 85/425] test_context
0:06:39 load avg: 1.26 [ 86/425] test_contextlib
0:06:39 load avg: 1.26 [ 87/425] test_contextlib_async
Task was destroyed but it is pending!
task: <Task pending name='Task-4436' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-4438' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-4443' coro=<<async_generator_athrow without __name__>()>>
0:06:40 load avg: 1.26 [ 88/425] test_copy
0:06:40 load avg: 1.26 [ 89/425] test_copyreg
0:06:40 load avg: 1.26 [ 90/425] test_coroutines
0:06:42 load avg: 1.24 [ 91/425] test_cprofile
0:06:43 load avg: 1.24 [ 92/425] test_crashers
0:06:43 load avg: 1.24 [ 93/425] test_crypt
0:06:44 load avg: 1.24 [ 94/425] test_csv
0:06:45 load avg: 1.24 [ 95/425] test_ctypes
0:06:48 load avg: 1.38 [ 96/425] test_curses
test test_curses failed -- Traceback (most recent call last):
  File "/opt/python/3.9.0/lib/python3.9/test/test_curses.py", line 289, in test_colors_funcs
    curses.pair_content(curses.COLOR_PAIRS - 1)
OverflowError: signed short integer is greater than maximum

0:06:49 load avg: 1.38 [ 97/425/1] test_dataclasses -- test_curses failed
0:06:49 load avg: 1.38 [ 98/425/1] test_datetime
0:06:55 load avg: 1.35 [ 99/425/1] test_dbm
0:06:55 load avg: 1.35 [100/425/1] test_dbm_dumb
0:06:56 load avg: 1.35 [101/425/1] test_dbm_gnu
0:06:56 load avg: 1.56 [102/425/1] test_dbm_ndbm
0:06:57 load avg: 1.56 [103/425/1] test_decimal
0:07:11 load avg: 1.58 [104/425/1] test_decorators
0:07:12 load avg: 1.58 [105/425/1] test_defaultdict
0:07:12 load avg: 1.58 [106/425/1] test_deque
0:07:17 load avg: 1.54 [107/425/1] test_descr
0:07:20 load avg: 1.54 [108/425/1] test_descrtut
0:07:21 load avg: 1.54 [109/425/1] test_devpoll
test_devpoll skipped -- test works only on Solaris OS family
0:07:21 load avg: 1.54 [110/425/1] test_dict_version -- test_devpoll skipped
0:07:22 load avg: 1.57 [111/425/1] test_dictcomps
0:07:22 load avg: 1.57 [112/425/1] test_dictviews
0:07:22 load avg: 1.57 [113/425/1] test_difflib
0:07:24 load avg: 1.57 [114/425/1] test_dis
0:07:25 load avg: 1.57 [115/425/1] test_distutils
0:07:30 load avg: 1.53 [116/425/1] test_docxmlrpc
0:07:34 load avg: 1.41 [117/425/1] test_dtrace
0:07:35 load avg: 1.41 [118/425/1] test_dynamic
0:07:35 load avg: 1.41 [119/425/1] test_dynamicclassattribute
0:07:36 load avg: 1.41 [120/425/1] test_eintr
0:07:43 load avg: 1.26 [121/425/1] test_email
0:07:50 load avg: 1.24 [122/425/1] test_embed
0:07:50 load avg: 1.24 [123/425/1] test_ensurepip
0:07:51 load avg: 1.24 [124/425/1] test_enum
0:07:51 load avg: 1.30 [125/425/1] test_enumerate
0:07:52 load avg: 1.30 [126/425/1] test_eof
0:07:53 load avg: 1.30 [127/425/1] test_epoll
0:07:55 load avg: 1.30 [128/425/1] test_errno
0:07:56 load avg: 1.30 [129/425/1] test_exception_hierarchy
0:07:56 load avg: 1.30 [130/425/1] test_exception_variations
0:07:57 load avg: 1.36 [131/425/1] test_extcall
0:07:57 load avg: 1.36 [132/425/1] test_faulthandler
0:08:23 load avg: 1.24 [133/425/1] test_fcntl
0:08:23 load avg: 1.24 [134/425/1] test_file
0:08:24 load avg: 1.24 [135/425/1] test_file_eintr
0:08:26 load avg: 1.22 [136/425/1] test_filecmp
0:08:27 load avg: 1.22 [137/425/1] test_fileinput
0:08:28 load avg: 1.22 [138/425/1] test_fileio
0:08:28 load avg: 1.22 [139/425/1] test_finalization
0:08:32 load avg: 1.20 [140/425/1] test_float
0:08:32 load avg: 1.20 [141/425/1] test_flufl
0:08:33 load avg: 1.20 [142/425/1] test_fnmatch
0:08:33 load avg: 1.20 [143/425/1] test_fork1
0:08:39 load avg: 1.19 [144/425/1] test_format
0:08:39 load avg: 1.19 [145/425/1] test_fractions
0:08:40 load avg: 1.19 [146/425/1] test_frame
0:08:41 load avg: 1.19 [147/425/1] test_frozen
0:08:41 load avg: 1.19 [148/425/1] test_fstring
0:08:42 load avg: 1.17 [149/425/1] test_ftplib
0:08:46 load avg: 1.17 [150/425/1] test_funcattrs
0:08:46 load avg: 1.24 [151/425/1] test_functools
0:08:47 load avg: 1.24 [152/425/1] test_future
0:08:48 load avg: 1.24 [153/425/1] test_future3
0:08:48 load avg: 1.24 [154/425/1] test_future4
0:08:49 load avg: 1.24 [155/425/1] test_future5
0:08:49 load avg: 1.24 [156/425/1] test_gc
0:08:56 load avg: 1.36 [157/425/1] test_gdb
test_gdb skipped -- test_gdb only works on source builds at the moment.
0:08:58 load avg: 1.36 [158/425/1] test_generator_stop -- test_gdb skipped
0:08:58 load avg: 1.36 [159/425/1] test_generators
0:08:59 load avg: 1.36 [160/425/1] test_genericalias
0:09:00 load avg: 1.36 [161/425/1] test_genericclass
0:09:00 load avg: 1.36 [162/425/1] test_genericpath
0:09:01 load avg: 1.36 [163/425/1] test_genexps
0:09:01 load avg: 1.41 [164/425/1] test_getargs2
0:09:02 load avg: 1.41 [165/425/1] test_getopt
0:09:02 load avg: 1.41 [166/425/1] test_getpass
0:09:03 load avg: 1.41 [167/425/1] test_gettext
0:09:04 load avg: 1.41 [168/425/1] test_glob
0:09:05 load avg: 1.41 [169/425/1] test_global
0:09:05 load avg: 1.41 [170/425/1] test_graphlib
0:09:06 load avg: 1.41 [171/425/1] test_grp
0:09:06 load avg: 1.41 [172/425/1] test_gzip
0:09:07 load avg: 1.45 [173/425/1] test_hash
0:09:09 load avg: 1.45 [174/425/1] test_hashlib
0:09:13 load avg: 1.42 [175/425/1] test_heapq
0:09:14 load avg: 1.42 [176/425/1] test_hmac
0:09:15 load avg: 1.42 [177/425/1] test_html
0:09:16 load avg: 1.42 [178/425/1] test_htmlparser
0:09:16 load avg: 1.42 [179/425/1] test_http_cookiejar
0:09:17 load avg: 1.63 [180/425/1] test_http_cookies
0:09:18 load avg: 1.63 [181/425/1] test_httplib
0:09:20 load avg: 1.63 [182/425/1] test_httpservers
0:09:23 load avg: 1.58 [183/425/1] test_idle
0:09:33 load avg: 1.57 [184/425/1] test_imaplib
0:09:56 load avg: 1.27 [185/425/1] test_imghdr
0:09:57 load avg: 1.27 [186/425/1] test_imp
0:09:58 load avg: 1.27 [187/425/1] test_import
0:10:00 load avg: 1.27 [188/425/1] test_importlib
0:10:03 load avg: 1.40 [189/425/1] test_index
0:10:04 load avg: 1.40 [190/425/1] test_inspect
0:10:06 load avg: 1.40 [191/425/1] test_int
0:10:06 load avg: 1.45 [192/425/1] test_int_literal
0:10:07 load avg: 1.45 [193/425/1] test_io
0:11:00 load avg: 1.22 [194/425/1] test_ioctl -- test_io passed in 53.3 sec
0:11:01 load avg: 1.22 [195/425/1] test_ipaddress
0:11:02 load avg: 1.28 [196/425/1] test_isinstance
0:11:02 load avg: 1.28 [197/425/1] test_iter
0:11:03 load avg: 1.28 [198/425/1] test_iterlen
0:11:04 load avg: 1.28 [199/425/1] test_itertools
0:11:09 load avg: 1.34 [200/425/1] test_json
0:11:13 load avg: 1.47 [201/425/1] test_keyword
0:11:14 load avg: 1.47 [202/425/1] test_keywordonlyarg
0:11:15 load avg: 1.47 [203/425/1] test_kqueue
test_kqueue skipped -- test works only on BSD
0:11:15 load avg: 1.47 [204/425/1] test_largefile -- test_kqueue skipped
0:11:16 load avg: 1.47 [205/425/1] test_lib2to3
0:11:58 load avg: 1.38 [206/425/1] test_linecache -- test_lib2to3 passed in 42.0 sec
0:11:58 load avg: 1.38 [207/425/1] test_list
0:12:00 load avg: 1.38 [208/425/1] test_listcomps
0:12:00 load avg: 1.38 [209/425/1] test_lltrace
0:12:01 load avg: 1.38 [210/425/1] test_locale
0:12:02 load avg: 1.43 [211/425/1] test_logging
0:12:21 load avg: 1.31 [212/425/1] test_long
0:12:26 load avg: 1.31 [213/425/1] test_longexp
0:12:27 load avg: 1.28 [214/425/1] test_lzma
0:12:32 load avg: 1.26 [215/425/1] test_mailbox
0:12:34 load avg: 1.26 [216/425/1] test_mailcap
0:12:34 load avg: 1.26 [217/425/1] test_marshal
0:12:35 load avg: 1.26 [218/425/1] test_math
0:12:39 load avg: 1.24 [219/425/1] test_memoryio
0:12:40 load avg: 1.24 [220/425/1] test_memoryview
0:12:44 load avg: 1.22 [221/425/1] test_metaclass
0:12:44 load avg: 1.22 [222/425/1] test_mimetypes
0:12:45 load avg: 1.22 [223/425/1] test_minidom
0:12:46 load avg: 1.22 [224/425/1] test_mmap
0:12:47 load avg: 1.20 [225/425/1] test_module
0:12:48 load avg: 1.20 [226/425/1] test_modulefinder
0:12:49 load avg: 1.20 [227/425/1] test_msilib
test_msilib skipped -- No module named 'msilib'
0:12:50 load avg: 1.20 [228/425/1] test_multibytecodec -- test_msilib skipped
0:12:52 load avg: 1.18 [229/425/1] test_multiprocessing_fork
abc0:13:57 load avg: 1.30 [230/425/1] test_multiprocessing_forkserver -- test_multiprocessing_fork passed in 1 min 5 sec
0:15:05 load avg: 0.97 [231/425/1] test_multiprocessing_main_handling -- test_multiprocessing_forkserver passed in 1 min 7 sec
0:15:15 load avg: 1.46 [232/425/1] test_multiprocessing_spawn
0:16:39 load avg: 1.64 [233/425/1] test_named_expressions -- test_multiprocessing_spawn passed in 1 min 24 sec
0:16:39 load avg: 1.64 [234/425/1] test_netrc
0:16:40 load avg: 1.64 [235/425/1] test_nis
0:16:41 load avg: 1.64 [236/425/1] test_nntplib
0:17:10 load avg: 1.43 [237/425/1] test_ntpath
0:17:11 load avg: 1.43 [238/425/1] test_numeric_tower
0:17:12 load avg: 1.48 [239/425/1] test_openpty
0:17:13 load avg: 1.48 [240/425/1] test_operator
0:17:13 load avg: 1.48 [241/425/1] test_optparse
0:17:14 load avg: 1.48 [242/425/1] test_ordered_dict
0:17:20 load avg: 1.52 [243/425/1] test_os
0:17:25 load avg: 1.56 [244/425/1] test_ossaudiodev
test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp'
0:17:25 load avg: 1.56 [245/425/1] test_osx_env -- test_ossaudiodev skipped
0:17:26 load avg: 1.56 [246/425/1] test_parser
0:17:27 load avg: 1.60 [247/425/1] test_pathlib
0:17:29 load avg: 1.60 [248/425/1] test_pdb
0:17:31 load avg: 1.60 [249/425/1] test_peepholer
0:17:32 load avg: 1.87 [250/425/1] test_peg_generator
0:17:33 load avg: 1.87 [251/425/1] test_peg_parser
0:17:34 load avg: 1.87 [252/425/1] test_pickle
0:17:52 load avg: 1.70 [253/425/1] test_picklebuffer
0:17:53 load avg: 1.70 [254/425/1] test_pickletools
0:17:56 load avg: 1.70 [255/425/1] test_pipes
0:17:57 load avg: 1.72 [256/425/1] test_pkg
0:17:58 load avg: 1.72 [257/425/1] test_pkgutil
0:17:59 load avg: 1.72 [258/425/1] test_platform
0:18:00 load avg: 1.72 [259/425/1] test_plistlib
0:18:01 load avg: 1.72 [260/425/1] test_poll
0:18:13 load avg: 1.55 [261/425/1] test_popen
0:18:14 load avg: 1.55 [262/425/1] test_poplib
0:18:18 load avg: 1.51 [263/425/1] test_positional_only_arg
0:18:19 load avg: 1.51 [264/425/1] test_posix
0:18:21 load avg: 1.51 [265/425/1] test_posixpath
0:18:22 load avg: 1.55 [266/425/1] test_pow
0:18:23 load avg: 1.55 [267/425/1] test_pprint
0:18:24 load avg: 1.55 [268/425/1] test_print
0:18:25 load avg: 1.55 [269/425/1] test_profile
0:18:26 load avg: 1.55 [270/425/1] test_property
0:18:27 load avg: 1.50 [271/425/1] test_pstats
0:18:28 load avg: 1.50 [272/425/1] test_pty
0:18:29 load avg: 1.50 [273/425/1] test_pulldom
0:18:29 load avg: 1.50 [274/425/1] test_pwd
test test_pwd failed -- Traceback (most recent call last):
  File "/opt/python/3.9.0/lib/python3.9/test/test_pwd.py", line 54, in test_values_extended
    self.assertIn(pwd.getpwuid(e.pw_uid), entriesbyuid[e.pw_uid])
AssertionError: pwd.struct_passwd(pw_name='nobody', pw_passwd='*', pw_uid=65534, pw_gid=65534, pw_gecos='User Nobody', pw_dir='/', pw_shell='/usr/bin/nologin') not found in [pwd.struct_passwd(pw_name='nobody', pw_passwd='x', pw_uid=65534, pw_gid=65534, pw_gecos='nobody', pw_dir='/', pw_shell='/usr/bin/nologin')]

0:18:30 load avg: 1.50 [275/425/2] test_py_compile -- test_pwd failed
0:18:31 load avg: 1.50 [276/425/2] test_pyclbr
0:18:34 load avg: 1.62 [277/425/2] test_pydoc
0:19:08 load avg: 1.59 [278/425/2] test_pyexpat -- test_pydoc passed in 33.2 sec
0:19:08 load avg: 1.59 [279/425/2] test_queue
0:19:18 load avg: 1.82 [280/425/2] test_quopri
0:19:19 load avg: 1.82 [281/425/2] test_raise
0:19:20 load avg: 1.82 [282/425/2] test_random
0:19:22 load avg: 1.91 [283/425/2] test_range
0:19:24 load avg: 1.91 [284/425/2] test_re
0:19:26 load avg: 1.91 [285/425/2] test_readline
0:19:27 load avg: 1.92 [286/425/2] test_regrtest
0:19:44 load avg: 1.93 [287/425/2] test_repl
0:19:45 load avg: 1.93 [288/425/2] test_reprlib
0:19:46 load avg: 1.93 [289/425/2] test_resource
0:19:47 load avg: 1.86 [290/425/2] test_richcmp
0:19:48 load avg: 1.86 [291/425/2] test_rlcompleter
0:19:49 load avg: 1.86 [292/425/2] test_robotparser
0:19:50 load avg: 1.86 [293/425/2] test_runpy
0:19:52 load avg: 1.95 [294/425/2] test_sax
0:19:53 load avg: 1.95 [295/425/2] test_sched
0:19:54 load avg: 1.95 [296/425/2] test_scope
0:19:55 load avg: 1.95 [297/425/2] test_script_helper
0:19:56 load avg: 1.95 [298/425/2] test_secrets
0:19:57 load avg: 1.87 [299/425/2] test_select
0:20:09 load avg: 1.73 [300/425/2] test_selectors
0:20:30 load avg: 1.65 [301/425/2] test_set
0:20:33 load avg: 1.60 [302/425/2] test_setcomps
0:20:34 load avg: 1.60 [303/425/2] test_shelve
0:20:35 load avg: 1.60 [304/425/2] test_shlex
0:20:36 load avg: 1.60 [305/425/2] test_shutil
0:20:37 load avg: 1.63 [306/425/2] test_signal
0:21:26 load avg: 1.31 [307/425/2] test_site -- test_signal passed in 48.4 sec
0:21:27 load avg: 1.77 [308/425/2] test_slice
0:21:28 load avg: 1.77 [309/425/2] test_smtpd
0:21:29 load avg: 1.77 [310/425/2] test_smtplib
0:21:31 load avg: 1.77 [311/425/2] test_smtpnet
0:21:34 load avg: 1.79 [312/425/2] test_sndhdr
0:21:35 load avg: 1.79 [313/425/2] test_socket
0:22:01 load avg: 1.30 [314/425/2] test_socketserver
0:22:03 load avg: 1.35 [315/425/2] test_sort
0:22:04 load avg: 1.35 [316/425/2] test_source_encoding
0:22:05 load avg: 1.35 [317/425/2] test_spwd
0:22:06 load avg: 1.35 [318/425/2] test_sqlite
0:22:08 load avg: 1.48 [319/425/2] test_ssl
Resource 'ipv6.google.com' is not available
0:22:13 load avg: 1.37 [320/425/2] test_startfile
test_startfile skipped -- object <module 'os' from '/opt/python/3.9.0/lib/python3.9/os.py'> has no attribute 'startfile'
0:22:13 load avg: 1.37 [321/425/2] test_stat -- test_startfile skipped
0:22:14 load avg: 1.37 [322/425/2] test_statistics
0:22:24 load avg: 1.46 [323/425/2] test_strftime
0:22:25 load avg: 1.46 [324/425/2] test_string
0:22:26 load avg: 1.46 [325/425/2] test_string_literals
0:22:28 load avg: 1.51 [326/425/2] test_stringprep
0:22:28 load avg: 1.51 [327/425/2] test_strptime
0:22:29 load avg: 1.51 [328/425/2] test_strtod
0:22:31 load avg: 1.51 [329/425/2] test_struct
0:22:33 load avg: 1.55 [330/425/2] test_structmembers
0:22:34 load avg: 1.55 [331/425/2] test_structseq
0:22:34 load avg: 1.55 [332/425/2] test_subclassinit
0:22:35 load avg: 1.55 [333/425/2] test_subprocess
0:23:48 load avg: 1.45 [334/425/2] test_sunau -- test_subprocess passed in 1 min 12 sec
0:23:49 load avg: 1.45 [335/425/2] test_sundry
0:23:50 load avg: 1.45 [336/425/2] test_super
0:23:50 load avg: 1.45 [337/425/2] test_symbol
0:23:51 load avg: 1.45 [338/425/2] test_symtable
0:23:52 load avg: 1.50 [339/425/2] test_syntax
0:23:53 load avg: 1.50 [340/425/2] test_sys
0:23:57 load avg: 1.46 [341/425/2] test_sys_setprofile
0:23:58 load avg: 1.46 [342/425/2] test_sys_settrace
0:23:59 load avg: 1.46 [343/425/2] test_sysconfig
0:24:00 load avg: 1.46 [344/425/2] test_syslog
0:24:01 load avg: 1.46 [345/425/2] test_tabnanny
0:24:02 load avg: 1.42 [346/425/2] test_tarfile
0:24:14 load avg: 1.66 [347/425/2] test_tcl
0:24:20 load avg: 1.69 [348/425/2] test_telnetlib
0:24:21 load avg: 1.69 [349/425/2] test_tempfile
0:24:22 load avg: 1.71 [350/425/2] test_textwrap
0:24:23 load avg: 1.71 [351/425/2] test_thread
0:24:25 load avg: 1.71 [352/425/2] test_threadedtempfile
0:24:26 load avg: 1.71 [353/425/2] test_threading
0:24:39 load avg: 2.13 [354/425/2] test_threading_local
0:24:41 load avg: 2.13 [355/425/2] test_threadsignals
0:24:47 load avg: 2.03 [356/425/2] test_time
0:24:50 load avg: 2.03 [357/425/2] test_timeit
0:24:51 load avg: 2.03 [358/425/2] test_timeout
0:25:01 load avg: 1.87 [359/425/2] test_tix
0:25:02 load avg: 1.88 [360/425/2] test_tk
test test_tk failed -- Traceback (most recent call last):
  File "/opt/python/3.9.0/lib/python3.9/tkinter/test/test_tkinter/test_widgets.py", line 939, in test_from
    self.checkFloatParam(widget, 'from', 100, 14.9, 15.1, conv=float_round)
  File "/opt/python/3.9.0/lib/python3.9/tkinter/test/widget_tests.py", line 106, in checkFloatParam
    self.checkParam(widget, name, value, conv=conv, **kwargs)
  File "/opt/python/3.9.0/lib/python3.9/tkinter/test/widget_tests.py", line 63, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/opt/python/3.9.0/lib/python3.9/tkinter/test/widget_tests.py", line 47, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 14.9 != 15.0

0:25:15 load avg: 1.96 [361/425/3] test_tokenize -- test_tk failed
0:26:26 load avg: 1.30 [362/425/3] test_tools -- test_tokenize passed in 1 min 10 sec
0:26:27 load avg: 1.30 [363/425/3] test_trace
0:26:34 load avg: 1.41 [364/425/3] test_traceback
0:26:36 load avg: 1.41 [365/425/3] test_tracemalloc
0:26:39 load avg: 1.53 [366/425/3] test_ttk_guionly
0:26:53 load avg: 2.09 [367/425/3] test_ttk_textonly
0:26:54 load avg: 2.09 [368/425/3] test_tuple
0:27:09 load avg: 2.08 [369/425/3] test_turtle
0:27:10 load avg: 2.08 [370/425/3] test_type_comments
0:27:11 load avg: 2.08 [371/425/3] test_typechecks
0:27:12 load avg: 2.08 [372/425/3] test_typing
0:27:13 load avg: 1.99 [373/425/3] test_ucn
0:27:14 load avg: 1.99 [374/425/3] test_unary
0:27:15 load avg: 1.99 [375/425/3] test_unicode
0:27:21 load avg: 1.91 [376/425/3] test_unicode_file
0:27:22 load avg: 1.91 [377/425/3] test_unicode_file_functions
0:27:23 load avg: 1.84 [378/425/3] test_unicode_identifiers
0:27:24 load avg: 1.84 [379/425/3] test_unicodedata
0:27:45 load avg: 2.02 [380/425/3] test_univnewlines
0:27:46 load avg: 2.02 [381/425/3] test_unpack
0:27:47 load avg: 2.02 [382/425/3] test_unpack_ex
0:27:48 load avg: 2.01 [383/425/3] test_unparse
0:28:49 load avg: 2.04 [384/425/3] test_urllib -- test_unparse passed in 1 min
0:28:50 load avg: 2.04 [385/425/3] test_urllib2
0:28:52 load avg: 2.12 [386/425/3] test_urllib2_localnet
0:28:54 load avg: 2.12 [387/425/3] test_urllib2net
0:29:02 load avg: 1.95 [388/425/3] test_urllib_response
0:29:03 load avg: 1.95 [389/425/3] test_urllibnet
0:29:06 load avg: 1.95 [390/425/3] test_urlparse
0:29:08 load avg: 2.19 [391/425/3] test_userdict
0:29:09 load avg: 2.19 [392/425/3] test_userlist
0:29:10 load avg: 2.19 [393/425/3] test_userstring
0:29:13 load avg: 2.18 [394/425/3] test_utf8_mode
0:29:15 load avg: 2.18 [395/425/3] test_utf8source
0:29:16 load avg: 2.18 [396/425/3] test_uu
0:29:17 load avg: 2.08 [397/425/3] test_uuid
0:29:19 load avg: 2.08 [398/425/3] test_venv
0:29:33 load avg: 2.00 [399/425/3] test_wait3
0:29:39 load avg: 2.00 [400/425/3] test_wait4
0:29:45 load avg: 2.16 [401/425/3] test_warnings
0:29:47 load avg: 2.16 [402/425/3] test_wave
0:29:48 load avg: 2.23 [403/425/3] test_weakref
0:30:35 load avg: 1.86 [404/425/3] test_weakset -- test_weakref passed in 47.2 sec
0:30:37 load avg: 1.86 [405/425/3] test_webbrowser
0:30:39 load avg: 1.87 [406/425/3] test_winconsoleio
test_winconsoleio skipped -- test only relevant on win32
0:30:39 load avg: 1.87 [407/425/3] test_winreg -- test_winconsoleio skipped
test_winreg skipped -- No module named 'winreg'
0:30:39 load avg: 1.87 [408/425/3] test_winsound -- test_winreg skipped
test_winsound skipped -- No module named 'winsound'
0:30:40 load avg: 1.87 [409/425/3] test_with -- test_winsound skipped
0:30:41 load avg: 1.87 [410/425/3] test_wsgiref
0:30:42 load avg: 1.87 [411/425/3] test_xdrlib
0:30:43 load avg: 1.88 [412/425/3] test_xml_dom_minicompat
0:30:44 load avg: 1.88 [413/425/3] test_xml_etree
0:30:47 load avg: 1.88 [414/425/3] test_xml_etree_c
0:30:51 load avg: 1.89 [415/425/3] test_xmlrpc
0:30:56 load avg: 1.90 [416/425/3] test_xmlrpc_net
0:30:57 load avg: 1.90 [417/425/3] test_xxtestfuzz
0:30:58 load avg: 1.99 [418/425/3] test_yield_from
0:30:59 load avg: 1.99 [419/425/3] test_zipapp
0:31:00 load avg: 1.99 [420/425/3] test_zipfile
0:31:11 load avg: 1.98 [421/425/3] test_zipfile64
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
0:31:12 load avg: 1.98 [422/425/3] test_zipimport -- test_zipfile64 skipped (resource denied)
0:31:13 load avg: 1.90 [423/425/3] test_zipimport_support
0:31:15 load avg: 1.90 [424/425/3] test_zlib
0:31:17 load avg: 1.90 [425/425/3] test_zoneinfo

== Tests result: FAILURE ==

409 tests OK.

3 tests failed:
    test_curses test_pwd test_tk

13 tests skipped:
    test_asdl_parser test_check_c_globals test_clinic test_devpoll
    test_gdb test_kqueue test_msilib test_ossaudiodev test_startfile
    test_winconsoleio test_winreg test_winsound test_zipfile64

Total duration: 31 min 18 sec
Tests result: FAILURE

----------
components: Tests
messages: 374344
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: python 3.9.0b5 test

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Sun Jul 26 17:23:49 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Sun, 26 Jul 2020 21:23:49 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595798629.62.0.356732036968.issue41340@roundup.psfhosted.org>


fj92f3jj923f923 <watashiwaher at gmail.com> added the comment:

I can give a try with removing
Please, wait
Thanks everyone for giving a chance to make a PR :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 17:46:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 21:46:40 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595800000.42.0.767530697735.issue40939@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

See also https://github.com/python/cpython/pull/19969 (Pablo's attempt at replacing the grammar in the reference docs with something derived from Grammar/python.gram).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Sun Jul 26 17:47:49 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 26 Jul 2020 21:47:49 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595800069.92.0.0333455053977.issue40939@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +20774
pull_request: https://github.com/python/cpython/pull/19969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Sun Jul 26 18:30:18 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Sun, 26 Jul 2020 22:30:18 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595802618.79.0.822888394608.issue41405@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

while compiling i got this warning, maybe its related!

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 -IObjects -IInclude -IPython -I. -I../Include    -DPy_BUILD_CORE -o Python/getcompiler.o ../Python/getcompiler.c
In function ?assemble_lnotab?,
    inlined from ?assemble_emit? at ../Python/compile.c:5714:25,
    inlined from ?assemble? at ../Python/compile.c:6053:18:
../Python/compile.c:5668:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 5668 |         *lnotab++ = k;
      |         ~~~~~~~~~~^~~

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Sun Jul 26 18:42:01 2020
From: report at bugs.python.org (David Halter)
Date: Sun, 26 Jul 2020 22:42:01 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1595803321.2.0.712601904142.issue40360@roundup.psfhosted.org>


David Halter <davidhalter88 at gmail.com> added the comment:

Parso's incremental parser is a terrible idea. It also works and is pretty fast, but the design is pretty terrible (it took me a lot of fuzzing to make sure that it works decently well).

The basic problem is that it's reusing nodes in a mutable way. If I were to redo it, I would probably choose a similar approach to Roslyn's red/green trees. It's probably also possible to use these approaches in Python, but they might be quite a bit slower than what I'm using (because recreating nodes can be quite expensive).

I imagine that one of the biggest issues with parsing PEG in parso would be to do it with error recovery AND incremental parsing. That combination can be quite annoying, but it's definitely still possible.

I'm not really sure about the future of parso with PEG. I'm definitely going to have to find a way to parse 3.10+ (so Jedi is going to keep working), however I feel like that it's hard to achieve a fast parser in pure Python. Parso is like 20% faster, but still more than ten times slower than the CPython parser...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Sun Jul 26 18:56:43 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Jul 2020 22:56:43 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1595804203.48.0.397491388447.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I guess the design space is wide open.

Does parso have to be pure Python? If not, we could generate C code like we do for CPython's parser. Now, that doesn't work for incremental parsing, but I did an alternative implementation that uses a stack machine, also in C, that's only 2x slower than the PEG parser. Maybe that could be adapted to incremental parsing (because it's a stack machine). Error recovery is still a research project (at least for me -- I'm actually reading papers :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Sun Jul 26 19:35:02 2020
From: report at bugs.python.org (Lewis Ball)
Date: Sun, 26 Jul 2020 23:35:02 +0000
Subject: [issue41388] IDLE fails to detect corresponding opening parenthesis
In-Reply-To: <1595617841.76.0.15009470661.issue41388@roundup.psfhosted.org>
Message-ID: <1595806502.22.0.563115706068.issue41388@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

Okay that makes sense. Removing things from _synchre would slow down the matching slightly, although the matching still seems plenty fast enough when done inside an if clause at the moment, so I'm not sure how noticeable the removal of `else` would be. One thing could be to search for `else:` instead of just `else` in _synchre, as only the former indicates the start of a new statement (although I guess it would actually have to check for `else[\s\\]*:` or something).

Like you say though, if there are other more pressing issues with the matching then maybe it is worth fixing them all at the same time. Happy to help with that if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41388>
_______________________________________

From report at bugs.python.org  Sun Jul 26 20:58:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jul 2020 00:58:48 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_Tk_window_not_going_full_screen_on_90=C2=B0_ro?=
 =?utf-8?q?tated__screen_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595811528.72.0.989989661291.issue41349@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: terry.reedy -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Sun Jul 26 21:44:06 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 27 Jul 2020 01:44:06 +0000
Subject: [issue30155] Add ability to get tzinfo from a datetime instance in C
 API
In-Reply-To: <1493047646.24.0.156322797242.issue30155@psf.upfronthosting.co.za>
Message-ID: <1595814246.86.0.00708105710618.issue30155@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 5.0 -> 6.0
pull_requests: +20775
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21633

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Sun Jul 26 21:46:10 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Mon, 27 Jul 2020 01:46:10 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595814370.84.0.157117455572.issue41340@roundup.psfhosted.org>


Change by fj92f3jj923f923 <watashiwaher at gmail.com>:


----------
pull_requests: +20776
pull_request: https://github.com/python/cpython/pull/21634

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 21:48:25 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jul 2020 01:48:25 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595814505.24.0.218917702066.issue41384@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset f1d40f941a6483b1d4ea10f1051ace7b426fb8e7 by Akuli in branch 'master':
bpo-41384: Raise TclError in tkinter.OptionMenu (GH-21601)
https://github.com/python/cpython/commit/f1d40f941a6483b1d4ea10f1051ace7b426fb8e7


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sun Jul 26 21:48:50 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jul 2020 01:48:50 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595814530.37.0.983125974134.issue41384@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +20777
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21635

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sun Jul 26 21:48:59 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jul 2020 01:48:59 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595814539.4.0.319152385638.issue41384@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20778
pull_request: https://github.com/python/cpython/pull/21636

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:00:03 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Mon, 27 Jul 2020 02:00:03 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595815203.8.0.0955322954988.issue41340@roundup.psfhosted.org>


fj92f3jj923f923 <watashiwaher at gmail.com> added the comment:

Created a new PR for removal of strdup (Hope it is correct)
https://github.com/python/cpython/pull/21634
Closed old one

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:00:41 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 27 Jul 2020 02:00:41 +0000
Subject: [issue30155] Add ability to get tzinfo from a datetime instance in C
 API
In-Reply-To: <1493047646.24.0.156322797242.issue30155@psf.upfronthosting.co.za>
Message-ID: <1595815241.12.0.336134189368.issue30155@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created PR 21633 to add these macros.  Please consider taking a look.

----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:14:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jul 2020 02:14:22 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595816062.17.0.883430286417.issue41384@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 8b052751d32c43540e2786ce0b3f7e4b4d0ae161 by Miss Islington (bot) in branch '3.9':
bpo-41384: Raise TclError in tkinter.OptionMenu (GH-21601)
https://github.com/python/cpython/commit/8b052751d32c43540e2786ce0b3f7e4b4d0ae161


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:14:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jul 2020 02:14:53 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595816093.21.0.797161355807.issue41384@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 104adedf641dc686069a20ae1a05c821b56e4aa4 by Miss Islington (bot) in branch '3.8':
bpo-41384: Raise TclError in tkinter.OptionMenu (GH-21601)
https://github.com/python/cpython/commit/104adedf641dc686069a20ae1a05c821b56e4aa4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:17:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jul 2020 02:17:20 +0000
Subject: [issue41384] tkinter raises TypeError when it's supposed to raise
 TclError
In-Reply-To: <1595602111.15.0.773557179803.issue41384@roundup.psfhosted.org>
Message-ID: <1595816240.77.0.487896790516.issue41384@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for reporting this.  In the future, you can suggest a fix on the issue, without a PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41384>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:16:47 2020
From: report at bugs.python.org (hudelgado)
Date: Mon, 27 Jul 2020 03:16:47 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1595819807.8.0.989231827541.issue24955@roundup.psfhosted.org>


hudelgado <live2trance at gmail.com> added the comment:

I took a look at it and have a some more questions.
The class MacOSX(BaseBrowser) seems to be broken because it uses 'OpenUrl' which doesn't work in most recent versions of applescript, also that class doesn't seem to be used anywhere, is it ok to remove it, or should left it as is?
Although that class isn't used it contained an hack to open local files that didn't exist in the class MacOSXOSAScript(BaseBrowser), i've added that hack to the MacOSXOSAScript.
Can you validate if everything seems ok with this changes?
I'm happy to adjust things according to what you suggest.

----------
Added file: https://bugs.python.org/file49341/24955.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:28:52 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 27 Jul 2020 03:28:52 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595820532.69.0.98463799823.issue41340@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 5798f787779006a94a55ec74a86da4627de90146 by wasiher in branch 'master':
bpo-41340: Removed fallback implementation for strdup (GH-21634)
https://github.com/python/cpython/commit/5798f787779006a94a55ec74a86da4627de90146


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:29:02 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 27 Jul 2020 03:29:02 +0000
Subject: [issue41340] Not very good strcpy implementation in
 cpython/Python/strdup.c
In-Reply-To: <1595154964.78.0.522638535626.issue41340@roundup.psfhosted.org>
Message-ID: <1595820542.7.0.437388502499.issue41340@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41340>
_______________________________________

From report at bugs.python.org  Mon Jul 27 00:07:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jul 2020 04:07:36 +0000
Subject: [issue41403] Uncaught AttributeError in unittest.mock._get_target
In-Reply-To: <1595790944.09.0.556229072962.issue41403@roundup.psfhosted.org>
Message-ID: <1595822856.1.0.92926470844.issue41403@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cjw296, mariocj89, michael.foord, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41403>
_______________________________________

From report at bugs.python.org  Mon Jul 27 00:12:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jul 2020 04:12:50 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595823170.76.0.54878229482.issue41405@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems they were two tests were reported individually : 

test_curses - https://bugs.python.org/issue36630
test_tk - https://bugs.python.org/issue41306

Please also include the output of /opt/python/3.9.0/bin/python3 -m test.pythoninfo

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:17:50 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 27 Jul 2020 06:17:50 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1595830670.77.0.341827530071.issue31904@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 855e68855eeb06f8f0319b3366d3a012c2ff2041 by pxinwr in branch 'master':
bpo-31904: Fix test_ftplib failures for VxWorks RTOS (GH-19447)
https://github.com/python/cpython/commit/855e68855eeb06f8f0319b3366d3a012c2ff2041


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:28:36 2020
From: report at bugs.python.org (wyz23x2)
Date: Mon, 27 Jul 2020 06:28:36 +0000
Subject: [issue40891] Use PEP 573 in functools
In-Reply-To: <1591468044.26.0.252061125305.issue40891@roundup.psfhosted.org>
Message-ID: <1595831316.36.0.0143838883395.issue40891@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
title: Use pep573 in functools -> Use PEP 573 in functools

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40891>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:32:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jul 2020 06:32:39 +0000
Subject: [issue40891] Use PEP 573 in functools
In-Reply-To: <1591468044.26.0.252061125305.issue40891@roundup.psfhosted.org>
Message-ID: <1595831559.3.0.296120282037.issue40891@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40891>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:40:04 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 27 Jul 2020 06:40:04 +0000
Subject: [issue41403] Uncaught AttributeError in unittest.mock._get_target
In-Reply-To: <1595790944.09.0.556229072962.issue41403@roundup.psfhosted.org>
Message-ID: <1595832004.49.0.0771950070513.issue41403@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Given that `mock.patch` is being used incorrectly here, the error message seems clear enough: It's saying there's a `Foo` object in place, and `rsplit` gives a strong indication that a string was expected.

Would adding type hints in mock.py be a resolution for this?

I'd be fine to see this bug closed with "wontfix", but will leave it open for now in case others feel strongly differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41403>
_______________________________________

From report at bugs.python.org  Mon Jul 27 03:21:01 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 27 Jul 2020 07:21:01 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1595781568.26.0.451779203455.issue18280@roundup.psfhosted.org>
Message-ID: <62211e3e-684d-6423-45ca-6847bb32511b@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks. afaik, double spacing is a 'feature' a programmer added to a
text processing language - of the WYSIWUG kind, because program's such
as troff/nroff
didn't need them. They, rather it, understood that a period followed by
a space indicated the end of a sentence.

On 26/07/2020 18:39, Serhiy Storchaka wrote:
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> I think they are not required, but recommended.
>
> >From https://www.python.org/dev/peps/pep-0008/#comments:
>
>    You should use two spaces after a sentence-ending period in multi- sentence comments, except after the final sentence.
>
> >From https://www.python.org/dev/peps/pep-0012/#general:
>
>    You must adhere to the Emacs convention of adding two spaces at the end of every sentence.
>
> AFAIK in English typography the space after a sentence-ending period is longer than spaces between words. In other European typographies they have the same width.

I thought it was where type setters, classically, used the break between
the endings of a sentence - additional 'kerning' could be applied there.

Anyway - final question: does .rst reformat line-lingths, or does it
present everything literally - only adding ``embellishments``. I have
been thinking
it does both - and, yet another convention for sentence endings is to
always start a sentence on a new line (and two new-lines indicate
start of a paragraph.

However, for now - double-spaces will remain - and I hope to remember to
add my own :)

> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue18280>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Mon Jul 27 03:27:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jul 2020 07:27:12 +0000
Subject: [issue40891] Use PEP 573 in functools
In-Reply-To: <1591468044.26.0.252061125305.issue40891@roundup.psfhosted.org>
Message-ID: <1595834832.11.0.766146256134.issue40891@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm dropping off the nosy list.  It's not something that I understand and can help with.  Adding Serhiy, he might be able to review this.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40891>
_______________________________________

From report at bugs.python.org  Mon Jul 27 03:28:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jul 2020 07:28:07 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595834887.3.0.941321634437.issue18280@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy:  -rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Mon Jul 27 03:46:09 2020
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 27 Jul 2020 07:46:09 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595835969.94.0.275098802346.issue18280@roundup.psfhosted.org>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy:  -mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:04:37 2020
From: report at bugs.python.org (Michal Arbet)
Date: Mon, 27 Jul 2020 08:04:37 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595615331.1.0.503430555524.issue41345@roundup.psfhosted.org>
Message-ID: <CAKz7_JT4XmHnf4DhA50Wo2vK_YX48JHHG4LOavdCOh3KvLVcPw@mail.gmail.com>


Michal Arbet <michal.arbet at ultimum.io> added the comment:

Hello,

Thank you very much for help, I created pull request for urllib3 ->
https://github.com/urllib3/urllib3/pull/1911
Can u just confirm that this could be fixed in urllib3 as it is in pull
request ? Have I fixed it by good way ?

Thanks.
Michal Arbet
( kevko )

p? 24. 7. 2020 v 20:29 odes?latel Guido van Rossum <report at bugs.python.org>
napsal:

>
> Guido van Rossum <guido at python.org> added the comment:
>
> This surely is some application corner case. Closing.
>
> ----------
> nosy: +gvanrossum
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41345>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:26:25 2020
From: report at bugs.python.org (Frost Ming)
Date: Mon, 27 Jul 2020 08:26:25 +0000
Subject: [issue41406] BufferedReader causes Popen.communicate losing the
 remaining output.
Message-ID: <1595838385.02.0.156491511968.issue41406@roundup.psfhosted.org>


New submission from Frost Ming <mianghong at gmail.com>:

The following snippet behaves differently between Windows and POSIX.

import subprocess
import time


p = subprocess.Popen("ls -l", shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

print(p.stdout.read(1))   # read 1 byte
print(p.communicate())    # Returns empty output

It works fine on Windows and Python 2.x(communicate() returning the remaining output). So from the best guess it should be the expected behavior.

The reason behind this is that Popen.stdout is a BufferedReader. It stores all output in the buffer when calling read(). However, communicate() and the lower API _communicate() use a lower level method os.read() to get the output, which does not respect the underlying buffer. When an empty output is retrieved the file object is closed then.

First time to submit a bug report and pardon me if I am getting anything wrong.

----------
components: 2to3 (2.x to 3.x conversion tool), IO, Library (Lib)
messages: 374366
nosy: Frost Ming, brett.cannon, vstinner
priority: normal
severity: normal
status: open
title: BufferedReader causes Popen.communicate losing the remaining output.
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41406>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:27:52 2020
From: report at bugs.python.org (Frost Ming)
Date: Mon, 27 Jul 2020 08:27:52 +0000
Subject: [issue41406] BufferedReader causes Popen.communicate losing the
 remaining output.
In-Reply-To: <1595838385.02.0.156491511968.issue41406@roundup.psfhosted.org>
Message-ID: <1595838472.1.0.427155521427.issue41406@roundup.psfhosted.org>


Change by Frost Ming <mianghong at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41406>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:47:23 2020
From: report at bugs.python.org (Philippe Ombredanne)
Date: Mon, 27 Jul 2020 08:47:23 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1595839643.91.0.059827076677.issue34723@roundup.psfhosted.org>


Philippe Ombredanne <pombredanne at nexb.com> added the comment:

?ahin Kureta you wrote:
> I know it is not finalized and released yet but are you going to
> implement Version 14.0.0 of the Unicode Standard? 
> It finally solves the issue of Turkish lower/upper case 'I' and 'i'.

Thank you for the pointer!

I guess this spec could likely be under consideration for Python when it becomes final (but unlikely before?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Mon Jul 27 05:01:59 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 27 Jul 2020 09:01:59 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_Tk_window_not_going_full_screen_on_90=C2=B0_ro?=
 =?utf-8?q?tated__screen_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1595840519.64.0.785519390227.issue41349@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I am unfortunately unable to reproduce the issue (with the method provided by Ronald), but the way to create a blank window (equivalent to `import tkinter; tkinter.Tk()`) is simply to run `wish` in a terminal without giving it any commands (using `exit` to escape the shell after the test).

----------
nosy: +epaine

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Mon Jul 27 05:22:43 2020
From: report at bugs.python.org (Tony Reix)
Date: Mon, 27 Jul 2020 09:22:43 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595841763.73.0.238086985523.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

On AIX 7.2, with libffi compiled with -O0 -g, I have:

1) Call to memchr thru memchr_args_hack
#0  0x09000000001b0d60 in memchr () from /usr/lib/libc.a(shr_64.o)
#1  0x09000000058487a0 in ffi_call_DARWIN () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2  0x0900000005847eec in ffi_call (cif=0xfffffff, fn=0xffffca90, rvalue=0xfffffff, avalue=0xffffca80) at ../src/powerpc/ffi_darwin.c:31
#3  0x09000000058f9900 in ?? ()
#4  0x09000000058ebb6c in ?? ()
#5  0x090000000109fc18 in _PyObject_MakeTpCall () from /opt/freeware/lib64/libpython3.8.so

r3             0xa000000003659e0        720575940382841312
r4             0x64     100
r5             0x7      7
(gdb) x/s $r3
0xa000000003659e0:      "abcdef"

2) Call to memchr thru memchr_args_hack2
#0  0x09000000001b0d60 in memchr () from /usr/lib/libc.a(shr_64.o)
#1  0x09000000058487a0 in ffi_call_DARWIN () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2  0x0900000005847eec in ffi_call (cif=0xfffffff, fn=0xffffca90, rvalue=0xfffffff, avalue=0xffffca80) at ../src/powerpc/ffi_darwin.c:31
#3  0x09000000058f9900 in ?? ()
#4  0x09000000058ebb6c in ?? ()
#5  0x090000000109fc18 in _PyObject_MakeTpCall () from /opt/freeware/lib64/libpython3.8.so

r3             0xa000000003659e0        720575940382841312
r4             0x64     100
r5             0x0      0

So, it looks like, when libffi is not compiled with -O but with -O0 -g, that in 64bit ffi_call_DARWIN() is call in both cases (memchr_args_hack and memchr_args_hack2).
However, as seen previously, it was not the case with libffi built with -O .

Moreover, we have in source code:
  switch (cif->abi)
    {
    case FFI_AIX:
      ffi_call_AIX(&ecif, -(long)cif->bytes, cif->flags, ecif.rvalue, fn,
                   FFI_FN(ffi_prep_args));
      break;
    case FFI_DARWIN:
      ffi_call_DARWIN(&ecif, -(long)cif->bytes, cif->flags, ecif.rvalue, fn,
                      FFI_FN(ffi_prep_args), cif->rtype);

Why calling ffi_call_DARWIN instead of ffi_call_AIX ?

Hummm Will rebuild libffi and python both with gcc -O0 -g -gdwarf and look at details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Mon Jul 27 05:26:01 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 27 Jul 2020 09:26:01 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1595841961.67.0.13538166787.issue34723@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

We don't update the unicodedata database in patch releases because updates are backwards incompatible. Python 3.9 will ship with 13.0. Python 3.10 is going to ship with 14.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Mon Jul 27 06:01:38 2020
From: report at bugs.python.org (DarrenDanielDay)
Date: Mon, 27 Jul 2020 10:01:38 +0000
Subject: [issue41407] Tricky behavior of builtin-function map
Message-ID: <1595844098.22.0.235301411882.issue41407@roundup.psfhosted.org>


New submission from DarrenDanielDay <Darren_Daniel_Day at hotmail.com>:

# The following is a tricky example:

# This is an example function that possibly raises `StopIteration`.
# In some cases, this function may raise `StopIteration` in the first iteration.
def raise_stop_iteration(param):
    if param == 10:
        raise StopIteration
    # Suppose this function will do some simple calculation
    return -param

# Then when we use builtin-function `map` and for-loop:

print('example 1'.center(30, '='))
for item in map(raise_stop_iteration, range(5)):
    print(item)
print('end of example 1'.center(30, '='))

# It works well. The output of example 1 is 0 to -4.
# But the following can be triky:

print('example 2'.center(30, '='))
for item in map(raise_stop_iteration, range(10, 20)):
    print(item)
print('end of example 2'.center(30, '='))

# The output of exapmle 2 is just nothing,
# and no errors are reported,
# because `map` simply let the exception spread upward when executing `raise_stop_iteration(10)`.
# However, the exception type is StopIteration, so the for-loop catches it and breaks the loop,
# assuming this is the end of the loop.
# When the exception raised from buggy mapping function is exactly `StopIteration`, 
# for example, functions implemented with builtin-function `next`, 
# it can be confusing to find the real issue.

# I think it might be better improved in this way:

class my_map:
    def __init__(self, mapping_function, *iterators):
        self.mapping = mapping_function
        self.iterators = iterators
    
    def __iter__(self):
        for parameter_tuple in zip(*self.iterators):
            try:
                yield self.mapping(*parameter_tuple)
            except BaseException as e:
                raise RuntimeError(*e.args) from e
        
# It works like the map in most cases:

print('example 3'.center(30, '='))
for item in my_map(raise_stop_iteration, range(5)):
    print(item)
print('end of example 3'.center(30, '='))

# And then, the crash of the buggy mapping function will be reported:
print('example 4'.center(30, '='))
for item in my_map(raise_stop_iteration, range(10, 20)):
    print(item)
print('end of example 4'.center(30, '='))

----------
components: Library (Lib)
files: issue.py
messages: 374371
nosy: DarrenDanielDay
priority: normal
severity: normal
status: open
title: Tricky behavior of builtin-function map
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49342/issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41407>
_______________________________________

From report at bugs.python.org  Mon Jul 27 06:54:35 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 27 Jul 2020 10:54:35 +0000
Subject: [issue41407] Tricky behavior of builtin-function map
In-Reply-To: <1595844098.22.0.235301411882.issue41407@roundup.psfhosted.org>
Message-ID: <1595847275.38.0.569178572853.issue41407@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Converting *all* exceptions into RuntimeError is certainly not a good idea, especially since you include KeyboardInterrupt and other non-errors.

I'm probably going to be on the losing side of this one (I lost the argument back when a similar issue was raised about comprehensions), but I argue that this is not a bug it is a useful feature.

Having the map function raise StopIteration is a good way for the map to halt the loop early, when it detects a special sentinel or condition. A few years ago the change to comprehensions broke my code so I changed to map, and now you want to break it again :-(

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41407>
_______________________________________

From report at bugs.python.org  Mon Jul 27 08:28:33 2020
From: report at bugs.python.org (Avinash Maddikonda)
Date: Mon, 27 Jul 2020 12:28:33 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
Message-ID: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>


New submission from Avinash Maddikonda <svasssakavi at gmail.com>:

Add a `clamp` function to the `math` module which does something like this:  
  
```py
def clamp(value=0.5, minimum=0, maximum=1):
    """Clamps the *value* between the *minimum* and *maximum* and returns it..

<And some extra explanatory documentation with examples>
"""

    return max(minimum, min(value, maximum))
```
  
Because even `C++` has built-in clamp function (`std::clamp`) (which can be used using `#include <math.h>`)

----------
components: Library (Lib)
messages: 374373
nosy: SFM61319
priority: normal
severity: normal
status: open
title: Add a `clamp` function to the `math` module
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 08:49:17 2020
From: report at bugs.python.org (Magnus Johnsson)
Date: Mon, 27 Jul 2020 12:49:17 +0000
Subject: [issue41398] cgi module, parse_multipart fails
In-Reply-To: <1595757503.98.0.375306375596.issue41398@roundup.psfhosted.org>
Message-ID: <1595854157.52.0.65692864686.issue41398@roundup.psfhosted.org>


Magnus Johnsson <magnusjjj at gmail.com> added the comment:

https://github.com/yohanboniface/falcon-multipart/issues/8

It would seem that the same issue pops up elsewhere. We do indeed set the content-type, as per the default examples for unity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41398>
_______________________________________

From report at bugs.python.org  Mon Jul 27 09:03:15 2020
From: report at bugs.python.org (Tony Reix)
Date: Mon, 27 Jul 2020 13:03:15 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595854995.71.0.189771791573.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

After adding traces and after rebuilding Python and libffi with -O0 -g -gdwarf, it appears that, still in 64bit, the bug is still there, but that ffi_call_AIX is called now instead of ffi_call_DARWIN from ffi_call() routine of ../src/powerpc/ffi_darwin.c (lines 915...).
???

# ./Pb.py
TONY: libffi: src/powerpc/ffi_darwin.c : FFI_AIX
TONY: libffi: cif->abi: 1  -(long)cif->bytes : -144  cif->flags : 8  ecif.rvalue : fffffffffffd1f0  fn: 9001000a0082640  FFI_FN(ffi_prep_args) : 9001000a0483be8
b'def'
TONY: libffi: src/powerpc/ffi_darwin.c : FFI_AIX
TONY: libffi: cif->abi: 1  -(long)cif->bytes : -144  cif->flags : 8  ecif.rvalue : fffffffffffd220  fn: 9001000a0082640  FFI_FN(ffi_prep_args) : 9001000a0483be8
b'def'
TONY: libffi: src/powerpc/ffi_darwin.c : FFI_AIX
TONY: libffi: cif->abi: 1  -(long)cif->bytes : -144  cif->flags : 8  ecif.rvalue : fffffffffffd220  fn: 9001000a0082640  FFI_FN(ffi_prep_args) : 9001000a0483be8
None

In 32bit with same build environment, a different code is run since the traces are not printed.

Thus, 32bit and 64bit are managed very differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Mon Jul 27 09:06:15 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 27 Jul 2020 13:06:15 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595855175.98.0.402152661627.issue18280@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +20780
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21639

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Mon Jul 27 09:18:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jul 2020 13:18:49 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595855929.22.0.648820012725.issue41408@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be a duplicate of https://bugs.python.org/issue36788

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:14:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jul 2020 14:14:16 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595859256.77.0.200068485983.issue41401@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There are two errors in test_io, both are not related to AIX.

The first one is in test_fspath_support. It is exposed on non-UTF-8 locales. AIX by accident use ISO8859-1 locale by default.

The second one is in test_reader_writer_close_error_on_close and related to garbage collector. Seems it is only exposed when run this test separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:16:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jul 2020 14:16:24 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595859384.76.0.714704643328.issue41401@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20781
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21640

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:18:55 2020
From: report at bugs.python.org (Akuli)
Date: Mon, 27 Jul 2020 14:18:55 +0000
Subject: [issue41409] deque.pop(index) is not supported
Message-ID: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>


New submission from Akuli <akuviljanen17 at gmail.com>:

The pop method of collections.deque can't be used like deque.pop(index), even though `del deque[index]` or deque.pop() without an argument works. This breaks the Liskov substitution principle because collections.abc.MutableMapping supports the .pop(index) usage. Is this intentional?

related typeshed issue: https://github.com/python/typeshed/issues/4364

----------
components: Library (Lib)
messages: 374378
nosy: Akuli
priority: normal
severity: normal
status: open
title: deque.pop(index) is not supported

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:26:12 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 27 Jul 2020 14:26:12 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595859384.8.0.339236347814.issue41401@roundup.psfhosted.org>
Message-ID: <e907f66b-7cb1-fb01-01dd-759cc7c28ca2@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Excellent!!

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]git pr 21640
remote: Enumerating objects: 50, done.
remote: Counting objects: 100% (50/50), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 58 (delta 46), reused 48 (delta 46), pack-reused 8
Unpacking objects: 100% (58/58), done.
>From https://github.com/python/cpython
?* [new ref]???????? refs/pull/21640/head -> pr_21640

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]./python -m test
test_io
0:00:00 Run tests sequentially
0:00:00 [1/1] test_io
test_io passed in 1 min

== Tests result: SUCCESS ==

1 test OK.

Total duration: 1 min
Tests result: SUCCESS

On 27/07/2020 16:16, Serhiy Storchaka wrote:
> Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:
>
>
> ----------
> keywords: +patch
> pull_requests: +20781
> stage:  -> patch review
> pull_request: https://github.com/python/cpython/pull/21640
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41401>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:26:57 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jul 2020 14:26:57 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595860017.14.0.432675634265.issue41409@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:28:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jul 2020 14:28:37 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595860117.57.0.6433272589.issue41409@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

deque is not a subclass of MutableMapping, so the Liskov substitution principle is not related here.

deque is not registered as a virtual subclass of MutableMapping and it lacks a number of MutableMapping methods.

>>> import collections.abc
>>> issubclass(collections.deque, collections.abc.MutableMapping)
False
>>> sorted(set(dir(collections.abc.MutableMapping)) - set(dir(collections.deque)))
['_MutableMapping__marker', '__abstractmethods__', '__module__', '__slots__', '_abc_impl', 'get', 'items', 'keys', 'popitem', 'setdefault', 'update', 'values']

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:30:22 2020
From: report at bugs.python.org (Akuli)
Date: Mon, 27 Jul 2020 14:30:22 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595860222.28.0.641906925138.issue41409@roundup.psfhosted.org>


Akuli <akuviljanen17 at gmail.com> added the comment:

I meant MutableSequence instead of MutableMapping. Oops.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:40:12 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 27 Jul 2020 14:40:12 +0000
Subject: [issue41386] Popen.wait does not account for negative return codes
In-Reply-To: <1595606081.95.0.551964515363.issue41386@roundup.psfhosted.org>
Message-ID: <1595860812.04.0.444560763557.issue41386@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> in the windows API they seam to not know whether to use a ulong or a uint

This usage requires C `long int` to be the same size as `int` in 64-bit Windows.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41386>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:38:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jul 2020 14:38:52 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595860732.05.0.184235748253.issue41409@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

>>> issubclass(collections.deque, collections.abc.MutableSequence)
True
>>> sorted(set(dir(collections.abc.MutableSequence)) - set(dir(collections.deque)))
['__abstractmethods__', '__module__', '__slots__', '_abc_impl']

Well, it is a bug.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 10:58:14 2020
From: report at bugs.python.org (Yuan)
Date: Mon, 27 Jul 2020 14:58:14 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595861894.54.0.745743481322.issue41409@roundup.psfhosted.org>


Yuan <pyslvs at gmail.com> added the comment:

Same status as slicing support from MutableSequence.

----------
nosy: +Yuan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:21:25 2020
From: report at bugs.python.org (Bob Kline)
Date: Mon, 27 Jul 2020 15:21:25 +0000
Subject: [issue41410] Opening a file in binary mode makes a difference on all
 platforms in Python 3
Message-ID: <1595863285.0.0.72970010693.issue41410@roundup.psfhosted.org>


New submission from Bob Kline <bkline at rksystems.com>:

The documentation for tempfile.mkstemp() says "If text is specified, it indicates whether to open the file in binary mode (the default) or text mode. On some platforms, this makes no difference." That might have been true for Python 2.x, but in Python 3, there are no platforms for which the choice whether to open a file in binary mode makes no difference.

----------
assignee: docs at python
components: Documentation
messages: 374385
nosy: bkline, docs at python
priority: normal
severity: normal
status: open
title: Opening a file in binary mode makes a difference on all platforms in Python 3
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41410>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:26:20 2020
From: report at bugs.python.org (Shubham Kumar Jha)
Date: Mon, 27 Jul 2020 15:26:20 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595863580.16.0.975875825259.issue41409@roundup.psfhosted.org>


Shubham Kumar Jha <skjha832 at gmail.com> added the comment:

Hi, I want to start contributing to CPython. Can I take up this issue?

----------
nosy: +ShubhamKJha

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:31:42 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jul 2020 15:31:42 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1595863902.4.0.682879738026.issue40841@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> This looks like a useful addition. I hope someone will take up the review!

Thank you guido!
I also think that this API is good to be added to the standard library and it would be very useful!

I hope that someone would like to interest in this issue ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:37:53 2020
From: report at bugs.python.org (Avinash Maddikonda)
Date: Mon, 27 Jul 2020 15:37:53 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595864273.21.0.800417439287.issue41408@roundup.psfhosted.org>


Avinash Maddikonda <svasssakavi at gmail.com> added the comment:

Oh, I didn't know that. But I was thinking of adding it to the math module and not as a built-in method. I mean, it is definitely more useful than copysign, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:50:42 2020
From: report at bugs.python.org (Tony Reix)
Date: Mon, 27 Jul 2020 15:50:42 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595865042.57.0.783338338899.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

Fedora32/x86_64 : Python v3.8.5 has been built.
Issue is still there, but different in debug or optimized mode.
Thus, change done in https://bugs.python.org/issue22273 did not fix this issue.

./Pb-3.8.5-debug.py :
#!/opt/freeware/src/packages/BUILD/Python-3.8.5/build/debug/python
...

i./Pb-3.8.5-optimized.py :
#!/opt/freeware/src/packages/BUILD/Python-3.8.5/build/optimized/python


BUILD=debug
export LD_LIBRARY_PATH=/opt/freeware/src/packages/BUILD/Python-3.8.5/build/debug:/usr/lib64:/usr/lib
export PYTHONPATH=/opt/freeware/src/packages/BUILD/Python-3.8.5/build/debug/Modules
./Pb-3.8.5-debug.py
b'def'
None
None

BUILD=optimized
export LD_LIBRARY_PATH=/opt/freeware/src/packages/BUILD/Python-3.8.5/build/optimized:/usr/lib64:/usr/lib
export PYTHONPATH=/opt/freeware/src/packages/BUILD/Python-3.8.5/build/optimized/Modules
+ ./Pb-3.8.5-optimized.py
b'def'
Pb-3.8.5.sh: line 6: 103569 Segmentation fault      (core dumped) ./Pb-3.8.5-$BUILD.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:52:07 2020
From: report at bugs.python.org (Shubham Kumar Jha)
Date: Mon, 27 Jul 2020 15:52:07 +0000
Subject: [issue41394] Document '_' in interpreter in shell tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595865127.3.0.856610382886.issue41394@roundup.psfhosted.org>


Shubham Kumar Jha <skjha832 at gmail.com> added the comment:

The link provided by Karthikeyan Singaravelan doesn't mention that `_` would only get the not-None values. It is a part of interpreter and hence should be documented there. If no one is working on a patch, I would like to submit one.

----------
nosy: +ShubhamKJha

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:52:10 2020
From: report at bugs.python.org (Tony Reix)
Date: Mon, 27 Jul 2020 15:52:10 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595865130.01.0.96682817328.issue38628@roundup.psfhosted.org>


Change by Tony Reix <tony.reix at atos.net>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:53:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jul 2020 15:53:25 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595865205.56.0.134591900142.issue41408@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I will leave it to math module experts to keep it open or close it. There wasn't strong consensus on adding it math module either without a discussion in python-ideas https://bugs.python.org/msg358789.

----------
nosy: +mark.dickinson, rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:58:23 2020
From: report at bugs.python.org (Tony Reix)
Date: Mon, 27 Jul 2020 15:58:23 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595865503.29.0.234519249114.issue38628@roundup.psfhosted.org>


Tony Reix <tony.reix at atos.net> added the comment:

Fedora32/x86_64 : Python v3.8.5 : optimized : uint type.

If, instead of using ulong type, the Pb.py program makes use of uint, the issue is different: see below.
This means that the issue depends on the length of the data.

BUILD=optimized
TYPE=int
export LD_LIBRARY_PATH=/opt/freeware/src/packages/BUILD/Python-3.8.5/build/optimized:/usr/lib64:/usr/lib
export PYTHONPATH=/opt/freeware/src/packages/BUILD/Python-3.8.5/build/optimized/Modules
./Pb-3.8.5-int-optimized.py
b'def'
None
None

# cat ./Pb-3.8.5-int-optimized.py
#!/opt/freeware/src/packages/BUILD/Python-3.8.5/build/optimized/python

# #!/opt/freeware/src/packages/BUILD/Python-3.8.5/python
#       #!/usr/bin/env python3

from ctypes import *

libc = CDLL('/usr/lib64/libc-2.31.so')

class MemchrArgsHack(Structure):
    _fields_ = [("s", c_char_p), ("c", c_uint), ("n", c_uint)]

memchr_args_hack = MemchrArgsHack()
memchr_args_hack.s = b"abcdef"
memchr_args_hack.c = ord('d')
memchr_args_hack.n = 7

class MemchrArgsHack2(Structure):
    _fields_ = [("s", c_char_p), ("c_n", c_uint * 2)]

memchr_args_hack2 = MemchrArgsHack2()
memchr_args_hack2.s = b"abcdef"
memchr_args_hack2.c_n[0] = ord('d')
memchr_args_hack2.c_n[1] = 7

print( CFUNCTYPE(c_char_p, c_char_p, c_uint, c_uint, c_void_p)(('memchr', libc))(b"abcdef", c_uint(ord('d')), c_uint(7), None))
print( CFUNCTYPE(c_char_p, MemchrArgsHack, c_void_p)(('memchr', libc))(memchr_args_hack, None))
print( CFUNCTYPE(c_char_p, MemchrArgsHack2, c_void_p)(('memchr', libc))(memchr_args_hack2, None))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:00:01 2020
From: report at bugs.python.org (Avinash Maddikonda)
Date: Mon, 27 Jul 2020 16:00:01 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595865601.33.0.185947503759.issue41408@roundup.psfhosted.org>


Avinash Maddikonda <svasssakavi at gmail.com> added the comment:

So should I delete/reject this now? Because I think it would be more useful than functions like copysign (I mean copysign can be written easily without confusion, but clamp is confusing sometimes as the max function takes minimum and the min of value and the maximum, and yet we have a copysign function but not a clamp built-in or a math module function).

(I'll delete/reject if you guys want me to, np)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:06:29 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Jul 2020 16:06:29 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595865989.94.0.180047975879.issue41045@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I was just just trying to link to someone the documentation for f-strings, but:
1) Searching "fstring" only returns two results about xdrlib[0];
2) Searching "f-string" returns many unrelated results[1];
3) The first (and closer) result (string -- Common string operations[2]) yields nothing while using ctrl+f with fstring, f-string, f', f";
4) at the top of that page there are two links in a "see also":
  * Text Sequence Type ? str[3]: it mentions raw strings at the beginning, but also yields no results for fstring, f-string, f', f";
  * String Methods[4]: that is another section of the previous page (so ctrl+f doesn't find anything), but has a link to "Format String Syntax"[5];
5) The "Format String Syntax" page[5] has another link in the middle of a paragraph that points to "formatted string literals", that eventually brings us to the right page[6];
6) the "right page"[6] has a wall of text with a block of code containing the grammar, luckily followed by a few examples.

I think we should:
1) add index entries for "f-string" and "fstring" in the relevant sections of the docs, so that they appear in the search result;
2) in the Text Sequence Type ? str[3] section, have a bullet list for f-strings, raw-strings, and possibly u-strings;
3) possibly use the term "f-string" in addition (or instead) of "formatted string literal", to make the pages more ctrl+f-friendly throughout the docs;
4) possibly have another more newbie-friendly section on f-string (compared to the lexical analysis page) in the tutorial, in the stdtypes page[7] (e.g. before the printf-style String Formatting" section[8]), or in the string page[2] (e.g. after the "Format String Syntax" section[10]);
5) possibly reorganize and consolidate the different sections about strings, string methods, str.format(), the format mini-language, f-strings, raw/unicode-strings, %-style formatting in a single page or two (a page for the docs and one for the grammar), since it seems to me that over the years these sections got a bit scattered around as they were being added.

If you think this is out of the scope of this issue, I can open a separate one.

[0]: https://docs.python.org/3/search.html?q=fstring
[1]: https://docs.python.org/3/search.html?q=f-string
[2]: https://docs.python.org/3/library/string.html
[3]: https://docs.python.org/3/library/stdtypes.html#textseq
[4]: https://docs.python.org/3/library/stdtypes.html#string-methods
[5]: https://docs.python.org/3/library/string.html#formatstrings
[6]: https://docs.python.org/3/reference/lexical_analysis.html#f-strings
[7]: https://docs.python.org/3/library/stdtypes.html
[8]: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

----------
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:13:21 2020
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 27 Jul 2020 16:13:21 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1595866401.83.0.381394824943.issue38628@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Tony, Please see my reply from 2020-02-05.  This is a known "bug" in Python ctypes.  This is documented in Python ctypes.  This will not be fixed.  This cannot be fixed.

Python ctypes converts the array to a structure and creates an incorrect libffi descriptor.  The call to libffi creates a "fake" descriptor (description of the arguments) that doesn't match the actual data.  It cannot work.

This should be closed as "wont fix".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:23:46 2020
From: report at bugs.python.org (Avinash Maddikonda)
Date: Mon, 27 Jul 2020 16:23:46 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595867026.38.0.957868098453.issue41408@roundup.psfhosted.org>


Change by Avinash Maddikonda <svasssakavi at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:23:28 2020
From: report at bugs.python.org (Avinash Maddikonda)
Date: Mon, 27 Jul 2020 16:23:28 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595867008.93.0.634664296598.issue41408@roundup.psfhosted.org>


Avinash Maddikonda <svasssakavi at gmail.com> added the comment:

Okay, I'm rejecting this issue. But please let me know/contribute if anyone is going to add a clamp function as a built-in method or a math module function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:25:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 16:25:40 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595867140.98.0.85976052775.issue41045@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Those are really good observations and proposals, Ezio! I agree that it might be better to separate them into a new issue. Can you also review https://github.com/python/cpython/pull/21552 (the second PR here by amaajemyfren)? Maybe it would actually make a good candidate for part (4) of your proposed solutions.

@Ama Aje My Fren: please look at my review of https://github.com/python/cpython/pull/21509 and implement my suggestions, then we can merge that one and close *this* issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:31:33 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Jul 2020 16:31:33 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
Message-ID: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

[Creating a new issue from #41045]

I was just just trying to link to someone the documentation for f-strings, but:
1) Searching "fstring" only returns two results about xdrlib[0];
2) Searching "f-string" returns many unrelated results[1];
3) The first (and closer) result (string -- Common string operations[2]) yields nothing while using ctrl+f with fstring, f-string, f', f";
4) at the top of that page there are two links in a "see also":
  * Text Sequence Type ? str[3]: it mentions raw strings at the beginning, but also yields no results for fstring, f-string, f', f";
  * String Methods[4]: that is another section of the previous page (so ctrl+f doesn't find anything), but has a link to "Format String Syntax"[5];
5) The "Format String Syntax" page[5] has another link in the middle of a paragraph that points to "formatted string literals", that eventually brings us to the right page[6];
6) the "right page"[6] has a wall of text with a block of code containing the grammar, luckily followed by a few examples.

I think we should:
1) add index entries for "f-string" and "fstring" in the relevant sections of the docs, so that they appear in the search result;
2) in the Text Sequence Type ? str[3] section, have a bullet list for f-strings, raw-strings, and possibly u-strings;
3) possibly use the term "f-string" in addition (or instead) of "formatted string literal", to make the pages more ctrl+f-friendly throughout the docs;
4) possibly have another more newbie-friendly section on f-string (compared to the lexical analysis page) in the tutorial, in the stdtypes page[7] (e.g. before the printf-style String Formatting" section[8]), or in the string page[2] (e.g. after the "Format String Syntax" section[10]);
5) possibly reorganize and consolidate the different sections about strings, string methods, str.format(), the format mini-language, f-strings, raw/unicode-strings, %-style formatting in a single page or two (a page for the docs and one for the grammar), since it seems to me that over the years these sections got a bit scattered around as they were being added.

[0]: https://docs.python.org/3/search.html?q=fstring
[1]: https://docs.python.org/3/search.html?q=f-string
[2]: https://docs.python.org/3/library/string.html
[3]: https://docs.python.org/3/library/stdtypes.html#textseq
[4]: https://docs.python.org/3/library/stdtypes.html#string-methods
[5]: https://docs.python.org/3/library/string.html#formatstrings
[6]: https://docs.python.org/3/reference/lexical_analysis.html#f-strings
[7]: https://docs.python.org/3/library/stdtypes.html
[8]: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

----------
assignee: docs at python
components: Documentation
messages: 374398
nosy: docs at python, eric.smith, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve and consolidate f-strings docs
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:33:18 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Jul 2020 16:33:18 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595867598.24.0.550271878192.issue41045@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I agree that it might be better to separate them into a new issue.

I created #41411.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:34:40 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 27 Jul 2020 16:34:40 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1595867680.12.0.357573088141.issue41411@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think this is an excellent idea. The main f-string docs being in a section titled "Lexical Analysis" never seemed very user-friendly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:36:21 2020
From: report at bugs.python.org (Stefano Mazzucco)
Date: Mon, 27 Jul 2020 16:36:21 +0000
Subject: [issue24599] urllib URLopener().open https url returns 501 Not
 Implemented when https_proxy env var is http://
In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za>
Message-ID: <1595867781.11.0.250550264049.issue24599@roundup.psfhosted.org>


Stefano Mazzucco <nospam at curso.re> added the comment:

Closing as this bug refers to versions of Python that have been EOL'd.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24599>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:41:48 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jul 2020 16:41:48 +0000
Subject: [issue41406] BufferedReader causes Popen.communicate losing the
 remaining output.
In-Reply-To: <1595838385.02.0.156491511968.issue41406@roundup.psfhosted.org>
Message-ID: <1595868108.73.0.699434875221.issue41406@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41406>
_______________________________________

From report at bugs.python.org  Mon Jul 27 12:53:08 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 16:53:08 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1595868788.34.0.223276311268.issue41411@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

It's basically an accident that the only f-strings docs are in the language reference. Yes, they should be there, and the text there is pretty good *for the reference*, but there isn't much about them elsewhere outside of the tutorial, so everything links there. Maybe we need a section on them in the library part, of intermediate complexity between what's in the tutorial an what's in the reference. This could be on equal footing with the descriptions of % formatting and .format(), which seem to be quite extensive. We might also be able to share some text between .format() and f-strings, since the `!x` and `:...` parts are treated identically AFAICT. This would be another refactoring of some part of the docs.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Mon Jul 27 13:07:35 2020
From: report at bugs.python.org (Martin Borus)
Date: Mon, 27 Jul 2020 17:07:35 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
Message-ID: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>


New submission from Martin Borus <mborus at gmail.com>:

I just installed Python 3.9.0b5 using the provided beta installer python-3.9.0b5-amd64 on a Windows7, 64bit machine.

I did the installation without the Py Launcher update, into the folder "c:\python39"

The installer finished without problem.

Running "cmd.exe", navigating to "c:\python39" and then running python.exe results in an error message popup which tells me in
German system language that the "api-ms-win-core-path-l1-1-0.dll" is missing on the computer. I googled for it and it seems that this dll is not a part of Windows 7.

Message:


---------------------------
python.exe - Systemfehler
---------------------------
Das Programm kann nicht gestartet werden, da api-ms-win-core-path-l1-1-0.dll auf dem Computer fehlt. Installieren Sie das Programm erneut, um das Problem zu beheben. 
---------------------------
OK   
---------------------------

----------
components: Windows
messages: 374403
nosy: Martin Borus, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: After installation on Windows7, 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll" missing and doesn't start
type: resource usage
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Mon Jul 27 13:14:09 2020
From: report at bugs.python.org (Martin Borus)
Date: Mon, 27 Jul 2020 17:14:09 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595870049.14.0.625388898411.issue41412@roundup.psfhosted.org>


Martin Borus <mborus at gmail.com> added the comment:

Changed "component" from "resource" to "crash" because it seems to fit better.

----------
type: resource usage -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Mon Jul 27 13:38:34 2020
From: report at bugs.python.org (Irv Kalb)
Date: Mon, 27 Jul 2020 17:38:34 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1595520574.7.0.502852260253.issue38946@roundup.psfhosted.org>
Message-ID: <6FF712CC-6319-43ED-AE05-9E0715F46009@furrypants.com>


Irv Kalb <Irv at furrypants.com> added the comment:

Right.  I'm struggling with this bug every day.

Irv

> On Jul 23, 2020, at 9:09 AM, Ned Deily <report at bugs.python.org> wrote:
> 
> 
> Ned Deily <nad at python.org> added the comment:
> 
> Ramon, I am not sure why you closed this issue. Perhaps it may no longer be a problem for you, but it has not yet been resolved for users of the python.org macOS installers.
> 
> ----------
> stage: resolved -> 
> status: closed -> open
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38946>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Mon Jul 27 13:58:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jul 2020 17:58:46 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595872726.09.0.633469092932.issue41401@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 67987acd5dc9776f55f4e139e2b3d9e7a6434d9f by Serhiy Storchaka in branch 'master':
bpo-41401: Fix test_fspath_support in test_io. (GH-21640)
https://github.com/python/cpython/commit/67987acd5dc9776f55f4e139e2b3d9e7a6434d9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:03:06 2020
From: report at bugs.python.org (Irv Kalb)
Date: Mon, 27 Jul 2020 18:03:06 +0000
Subject: [issue41413] At prompt for input(), pressing Command q kills IDLE
Message-ID: <1595872986.33.0.489785676605.issue41413@roundup.psfhosted.org>


New submission from Irv Kalb <Irv at furrypants.com>:

This is probably related to earlier problems with running IDLE on MacOS Catalina:

Environment:

MacOS Catalina:  10.15.5
Python: 3.7.3
IDLE: 3.7.3

Steps to reproduce:

- Open IDLE, create a new file.  (Can reopen this file again for subsequent tests.)

- Code can consist of a single line:

dontCare = input('While this prompt for input is up, press Command q: ')

- Save and run

- When you see the prompt, press Command q to quit.

- See correct dialog box:  Your program is still running!  Do you want to kill it?

- Press OK.

Results:

- Python program quits.  Source file window closes. IDLE is left in an "unstable" state with only the IDLE menu option available.

At this point, any attempt to do anything with IDLE crashes IDLE, and shows a Mac system dialog box:

IDLE quit unexpectedly.  Click Reopen to open the application. Click Report to .....


Note:  This is not a huge deal because I have to restart IDLE anyway because of a bug 38946, which does not allow me to allow me to double click on a Python file if IDLE is already running.  But I thought this new information might help track things down.



I have run in to this because I am correcting many student's homework files, where I ask them to build a loop where they ask the user for information, do some processing, and generate output with that information.  Then the loop goes around again and asks for input again.  I want to quit the application at that point, but I always end up crashing IDLE.

----------
assignee: terry.reedy
components: IDLE, macOS
messages: 374407
nosy: IrvKalb, ned.deily, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: At prompt for input(), pressing Command q kills IDLE
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:03:53 2020
From: report at bugs.python.org (Constant Marks)
Date: Mon, 27 Jul 2020 18:03:53 +0000
Subject: [issue41362] Regenerating parser table fails (windows)
In-Reply-To: <1595351360.26.0.0463175809492.issue41362@roundup.psfhosted.org>
Message-ID: <1595873033.74.0.903972425963.issue41362@roundup.psfhosted.org>


Constant Marks <crmarksv at gmail.com> added the comment:

Thanks for the help.  I got my modification working by modifying the python.gram file and running build.bat --regen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41362>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:07:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jul 2020 18:07:46 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1595873266.23.0.874504200706.issue41401@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Automatic backport does not work due to changes in the test.support module. Victor, do you mind to backport PR 21640 to 3.9 and 3.8?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:20:44 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 18:20:44 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595874044.43.0.905045792181.issue40939@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 72cabb2aa636272e608285f5a6ba83b62be9be4e by Pablo Galindo in branch 'master':
bpo-40939: Use the new grammar for the grammar specification documentation (GH-19969)
https://github.com/python/cpython/commit/72cabb2aa636272e608285f5a6ba83b62be9be4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:27:07 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 27 Jul 2020 18:27:07 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595874427.94.0.0444905619079.issue41412@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> running python.exe results in an error message popup which tells me ...
> that the "api-ms-win-core-path-l1-1-0.dll" is missing on the computer. 
> I googled for it and it seems that this dll is not a part of Windows 7.

Microsoft ended extended support for Windows 7 back in January of this year, so Python 3.9 does not support Windows 7, in accordance with PEP 11 [1]. I'd expect the installer to fail on unsupported versions of Windows.

[1]: https://www.python.org/dev/peps/pep-0011/#microsoft-windows

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:31:35 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 18:31:35 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595874695.62.0.827464311973.issue40939@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +20782
pull_request: https://github.com/python/cpython/pull/21641

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:35:16 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Jul 2020 18:35:16 +0000
Subject: [issue41413] At prompt for input(), pressing Command q kills IDLE
In-Reply-To: <1595872986.33.0.489785676605.issue41413@roundup.psfhosted.org>
Message-ID: <1595874916.91.0.422905254891.issue41413@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report. Actually this behavior is not specific to running IDLE on macOS, it's also reproducible on Linux and on all current versions of IDLE.

----------
components:  -macOS
nosy:  -ronaldoussoren
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:38:59 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 18:38:59 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595875139.77.0.603933873253.issue40939@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The old parser is completely gone from the 3.10 branch. Closing.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:47:16 2020
From: report at bugs.python.org (Diogo Flores)
Date: Mon, 27 Jul 2020 18:47:16 +0000
Subject: [issue39959] Bug on multiprocessing.shared_memory
In-Reply-To: <1584128583.89.0.486447704556.issue39959@roundup.psfhosted.org>
Message-ID: <1595875636.0.0.013946945669.issue39959@roundup.psfhosted.org>


Diogo Flores <dxflores at outlook.com> added the comment:

I have tried a different approach using https://gitlab.com/tenzing/shared-array and I got it to perform well on Linux. 
Basically, the code above places all numpy arrays in /dev/shm which allows you to access and modify them from any number of processes without creating any copies; for deleting is equally simple - The code provides a SharedArray.list() to list all objects that itself placed in /dev/shm and so one can just iterate over the list and delete each element. (An easier approach is to use PathLib and just unlik all shared memory objects in /dev/shm)

I guess a solution based on Mat's code could be adapted to try and solve  the shared-memory problems.

I look forward for further discussion on the subject.

Diogo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:57:57 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 27 Jul 2020 18:57:57 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595876277.44.0.775228365574.issue40939@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +20783
pull_request: https://github.com/python/cpython/pull/21642

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Mon Jul 27 14:58:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jul 2020 18:58:26 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595876306.44.0.118796542765.issue41409@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Hi, I want to start contributing to CPython. Can I take up this issue?

Sure, go ahead. Feel free to ping one of us in the PR for review

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 15:00:50 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 19:00:50 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595876450.05.0.179325967756.issue40939@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset e6b2d93f0c3891827f609ecac1ced21e1626ed0a by Guido van Rossum in branch '3.9':
[3.9] bpo-40939: Use the new grammar for the grammar specification documentation (GH-19969) (#21641)
https://github.com/python/cpython/commit/e6b2d93f0c3891827f609ecac1ced21e1626ed0a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Mon Jul 27 15:53:06 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jul 2020 19:53:06 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1595879586.53.0.419444518361.issue40939@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b3fbff7289176ba1a322e6899c3d4a04880ed5a7 by Lysandros Nikolaou in branch 'master':
bpo-40939: Remove even more references to the old parser (GH-21642)
https://github.com/python/cpython/commit/b3fbff7289176ba1a322e6899c3d4a04880ed5a7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40939>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:01:37 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 27 Jul 2020 20:01:37 +0000
Subject: [issue41000] IDLE: only allow single instance
In-Reply-To: <1592385738.41.0.899337100123.issue41000@roundup.psfhosted.org>
Message-ID: <1595880097.25.0.710869410727.issue41000@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Is it worth me developing a PR for this issue, as it may be a suitable fix for #38946? (I am not guaranteeing any code, though, but I will try). If not, I will probably close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41000>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:03:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jul 2020 20:03:35 +0000
Subject: [issue41059] Large number of Coverity reports for parser.c
In-Reply-To: <1592679391.13.0.913540149945.issue41059@roundup.psfhosted.org>
Message-ID: <1595880215.22.0.951485401448.issue41059@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I tried reprodicing the coverity results using cppcheck (I don't have access to the coverity project, someone needs to approve :() and I got just a dozen of results:

? cppcheck Parser/parser.c --enable=style
Checking Parser/parser.c ...
Parser/parser.c:3280:22: style: Condition '_res==NULL' is always false [knownConditionTrueFalse]
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:3275:16: note: Assuming that condition 'a=_gather_33_rule(p)' is not redundant
            (a = _gather_33_rule(p))  // ','.import_from_as_name+
               ^
Parser/parser.c:3279:20: note: Assignment '_res=a', assigned value is 0
            _res = a;
                   ^
Parser/parser.c:3280:22: note: Condition '_res==NULL' is always false
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:3365:22: style: Condition '_res==NULL' is always false [knownConditionTrueFalse]
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:3360:16: note: Assuming that condition 'a=_gather_36_rule(p)' is not redundant
            (a = _gather_36_rule(p))  // ','.dotted_as_name+
               ^
Parser/parser.c:3364:20: note: Assignment '_res=a', assigned value is 0
            _res = a;
                   ^
Parser/parser.c:3365:22: note: Condition '_res==NULL' is always false
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:6072:22: style: Condition '_res==NULL' is always false [knownConditionTrueFalse]
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:6067:16: note: Assuming that condition 'a=_loop1_68_rule(p)' is not redundant
            (a = _loop1_68_rule(p))  // (('@' named_expression NEWLINE))+
               ^
Parser/parser.c:6071:20: note: Assignment '_res=a', assigned value is 0
            _res = a;
                   ^
Parser/parser.c:6072:22: note: Condition '_res==NULL' is always false
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:10662:22: style: Condition '_res==NULL' is always false [knownConditionTrueFalse]
            if (_res == NULL && PyErr_Occurred()) {
                     ^
Parser/parser.c:10657:16: note: Assuming that condition 'a=expression_rule(p)' is not redundant
            (a = expression_rule(p))  // expression
               ^
Parser/parser.c:10661:20: note: Assignment '_res=a', assigned value is 0
            _res = a;
                   ^
Parser/parser.c:10662:22: note: Condition '_res==NULL' is always false
            if (_res == NULL && PyErr_Occurred()) {

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41059>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:08:05 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Mon, 27 Jul 2020 20:08:05 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595880485.32.0.227251302391.issue41405@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

>>> /opt/python/3.9.0/bin/python3 -m test.pythoninfo
Python debug information
========================

CC.version: gcc (GCC) 10.1.0
Py_DEBUG: No (sys.gettotalrefcount() missing)
_decimal.__libmpdec_version__: 2.5.0
builtins.float.double_format: IEEE, little-endian
builtins.float.float_format: IEEE, little-endian
config[_config_init]: 2
config[_init_main]: 1
config[_install_importlib]: 1
config[_isolated_interpreter]: 0
config[_orig_argv]: ['/opt/python/3.9.0/bin/python3', '-m', 'test.pythoninfo']
config[_use_peg_parser]: 1
config[argv]: ['-m']
config[base_exec_prefix]: '/opt/python/3.9.0'
config[base_executable]: '/opt/python/3.9.0/bin/python3'
config[base_prefix]: '/opt/python/3.9.0'
config[buffered_stdio]: 1
config[bytes_warning]: 0
config[check_hash_pycs_mode]: 'default'
config[configure_c_stdio]: 1
config[dev_mode]: 0
config[dump_refs]: 0
config[exec_prefix]: '/opt/python/3.9.0'
config[executable]: '/opt/python/3.9.0/bin/python3'
config[faulthandler]: 0
config[filesystem_encoding]: 'utf-8'
config[filesystem_errors]: 'surrogateescape'
config[hash_seed]: 0
config[home]: None
config[import_time]: 0
config[inspect]: 0
config[install_signal_handlers]: 1
config[interactive]: 0
config[isolated]: 0
config[malloc_stats]: 0
config[module_search_paths]: ['/opt/python/3.9.0/lib/python39.zip', '/opt/python/3.9.0/lib/python3.9', '/opt/python/3.9.0/lib/python3.9/lib-dynload']
config[optimization_level]: 0
config[parse_argv]: 1
config[parser_debug]: 0
config[pathconfig_warnings]: 1
config[platlibdir]: 'lib'
config[prefix]: '/opt/python/3.9.0'
config[program_name]: '/opt/python/3.9.0/bin/python3'
config[pycache_prefix]: None
config[pythonpath_env]: None
config[quiet]: 0
config[run_command]: None
config[run_filename]: None
config[run_module]: 'test.pythoninfo'
config[show_ref_count]: 0
config[site_import]: 1
config[skip_source_first_line]: 0
config[stdio_encoding]: 'utf-8'
config[stdio_errors]: 'strict'
config[tracemalloc]: 0
config[use_environment]: 1
config[use_hash_seed]: 0
config[user_site_directory]: 1
config[verbose]: 0
config[warnoptions]: []
config[write_bytecode]: 1
config[xoptions]: []
datetime.datetime.now: 2020-07-27 14:03:42.099769
expat.EXPAT_VERSION: expat_2.2.8
fips.openssl_fips_mode: 0
gdb_version: GNU gdb (GDB) 9.2
gdbm.GDBM_VERSION: 1.18.1
global_config[Py_BytesWarningFlag]: 0
global_config[Py_DebugFlag]: 0
global_config[Py_DontWriteBytecodeFlag]: 0
global_config[Py_FileSystemDefaultEncodeErrors]: 'surrogateescape'
global_config[Py_FileSystemDefaultEncoding]: 'utf-8'
global_config[Py_FrozenFlag]: 0
global_config[Py_HasFileSystemDefaultEncoding]: 0
global_config[Py_HashRandomizationFlag]: 1
global_config[Py_IgnoreEnvironmentFlag]: 0
global_config[Py_InspectFlag]: 0
global_config[Py_InteractiveFlag]: 0
global_config[Py_IsolatedFlag]: 0
global_config[Py_NoSiteFlag]: 0
global_config[Py_NoUserSiteDirectory]: 0
global_config[Py_OptimizeFlag]: 0
global_config[Py_QuietFlag]: 0
global_config[Py_UTF8Mode]: 0
global_config[Py_UnbufferedStdioFlag]: 0
global_config[Py_VerboseFlag]: 0
global_config[_Py_HasFileSystemDefaultEncodeErrors]: 0
locale.encoding: UTF-8
os.cpu_count: 16
os.environ[DISPLAY]: :0
os.environ[HOME]: /home/stealth
os.environ[LANG]: en_CA.UTF-8
os.environ[LC_ADDRESS]: en_CA.UTF-8
os.environ[LC_IDENTIFICATION]: en_CA.UTF-8
os.environ[LC_MEASUREMENT]: en_CA.UTF-8
os.environ[LC_MONETARY]: en_CA.UTF-8
os.environ[LC_NAME]: en_CA.UTF-8
os.environ[LC_NUMERIC]: en_CA.UTF-8
os.environ[LC_PAPER]: en_CA.UTF-8
os.environ[LC_TELEPHONE]: en_CA.UTF-8
os.environ[LC_TIME]: en_CA.UTF-8
os.environ[PATH]: /home/stealth/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/opt/cuda/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
os.environ[SHELL]: /bin/bash
os.environ[TERM]: xterm-256color
os.getcwd: /home/stealth
os.getegid: 1000
os.geteuid: 1000
os.getgid: 1000
os.getgrouplist: 1000, 3, 7, 10, 90, 91, 93, 95, 96, 98, 619
os.getgroups: 3, 7, 10, 90, 91, 93, 95, 96, 98, 619, 1000
os.getloadavg: (0.26, 0.6, 0.59)
os.getrandom: ready (initialized)
os.getresgid: (1000, 1000, 1000)
os.getresuid: (1000, 1000, 1000)
os.getuid: 1000
os.login: stealth
os.name: posix
os.supports_bytes_environ: True
os.supports_effective_ids: ['access']
os.supports_fd: ['chdir', 'chmod', 'chown', 'execve', 'listdir', 'pathconf', 'scandir', 'stat', 'statvfs', 'truncate', 'utime']
os.supports_follow_symlinks: ['access', 'chown', 'link', 'stat', 'utime']
os.umask: 0o022
os.uname: posix.uname_result(sysname='Linux', nodename='stealth', release='5.8.0-1-MANJARO', version='#1 SMP PREEMPT Sun Jul 26 22:13:04 UTC 2020', machine='x86_64')
platform.architecture: 64bit ELF
platform.libc_ver: glibc 2.31
platform.platform: Linux-5.8.0-1-MANJARO-x86_64-with-glibc2.31
platform.python_implementation: CPython
pre_config[_config_init]: 2
pre_config[allocator]: 0
pre_config[coerce_c_locale]: 0
pre_config[coerce_c_locale_warn]: 0
pre_config[configure_locale]: 1
pre_config[dev_mode]: 0
pre_config[isolated]: 0
pre_config[parse_argv]: 1
pre_config[use_environment]: 1
pre_config[utf8_mode]: 0
pwd.getpwuid(1000): pwd.struct_passwd(pw_name='stealth', pw_passwd='x', pw_uid=1000, pw_gid=1000, pw_gecos='STEALTH', pw_dir='/home/stealth', pw_shell='/bin/bash')
pymem.allocator: pymalloc
pymem.with_pymalloc: True
readline._READLINE_LIBRARY_VERSION: 8.0
readline._READLINE_RUNTIME_VERSION: 0x800
readline._READLINE_VERSION: 0x800
resource.RLIMIT_AS: (-1, -1)
resource.RLIMIT_CORE: (-1, -1)
resource.RLIMIT_CPU: (-1, -1)
resource.RLIMIT_DATA: (-1, -1)
resource.RLIMIT_FSIZE: (-1, -1)
resource.RLIMIT_MEMLOCK: (-1, -1)
resource.RLIMIT_MSGQUEUE: (819200, 819200)
resource.RLIMIT_NICE: (0, 0)
resource.RLIMIT_NOFILE: (1024, 524288)
resource.RLIMIT_NPROC: (47892, 47892)
resource.RLIMIT_OFILE: (1024, 524288)
resource.RLIMIT_RSS: (-1, -1)
resource.RLIMIT_RTPRIO: (0, 0)
resource.RLIMIT_RTTIME: (-1, -1)
resource.RLIMIT_SIGPENDING: (47892, 47892)
resource.RLIMIT_STACK: (8388608, -1)
resource.pagesize: 4096
socket.hostname: stealth
sqlite3.sqlite_version: 3.32.3
sqlite3.version: 2.6.0
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1g  21 Apr 2020
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 7, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000
ssl.SSLContext.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.SSLContext.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.SSLContext.protocol: _SSLMethod.PROTOCOL_TLS
ssl.SSLContext.verify_mode: VerifyMode.CERT_NONE
ssl.default_https_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.default_https_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.default_https_context.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.default_https_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.default_https_context.verify_mode: VerifyMode.CERT_REQUIRED
ssl.stdlib_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.stdlib_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.stdlib_context.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.stdlib_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.stdlib_context.verify_mode: VerifyMode.CERT_NONE
subprocess._USE_POSIX_SPAWN: True
sys.api_version: 1013
sys.builtin_module_names: ('_abc', '_ast', '_codecs', '_collections', '_functools', '_imp', '_io', '_locale', '_operator', '_peg_parser', '_signal', '_sre', '_stat', '_string', '_symtable', '_thread', '_tracemalloc', '_warnings', '_weakref', 'atexit', 'builtins', 'errno', 'faulthandler', 'gc', 'itertools', 'marshal', 'posix', 'pwd', 'sys', 'time', 'xxsubtype')
sys.byteorder: little
sys.dont_write_bytecode: False
sys.executable: /opt/python/3.9.0/bin/python3
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=0)
sys.float_info: sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)
sys.float_repr_style: short
sys.hash_info: sys.hash_info(width=64, modulus=2305843009213693951, inf=314159, nan=0, imag=1000003, algorithm='siphash24', hash_bits=64, seed_bits=128, cutoff=0)
sys.hexversion: 50921653
sys.implementation: namespace(name='cpython', cache_tag='cpython-39', version=sys.version_info(major=3, minor=9, micro=0, releaselevel='beta', serial=5), hexversion=50921653, _multiarch='x86_64-linux-gnu')
sys.int_info: sys.int_info(bits_per_digit=30, sizeof_digit=4)
sys.maxsize: 9223372036854775807
sys.maxunicode: 1114111
sys.path: ['/home/stealth', '/opt/python/3.9.0/lib/python39.zip', '/opt/python/3.9.0/lib/python3.9', '/opt/python/3.9.0/lib/python3.9/lib-dynload', '/home/stealth/.local/lib/python3.9/site-packages', '/opt/python/3.9.0/lib/python3.9/site-packages']
sys.platform: linux
sys.prefix: /opt/python/3.9.0
sys.stderr.encoding: utf-8/backslashreplace
sys.stdin.encoding: utf-8/strict
sys.stdout.encoding: utf-8/strict
sys.thread_info: sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.31')
sys.version: 3.9.0b5 (default, Jul 26 2020, 16:24:14)  [GCC 10.1.0]
sys.version_info: sys.version_info(major=3, minor=9, micro=0, releaselevel='beta', serial=5)
sysconfig[CCSHARED]: -fPIC
sysconfig[CC]: gcc -pthread
sysconfig[CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[CONFIG_ARGS]: '--prefix=/opt/python/3.9.0'
sysconfig[HOST_GNU_TYPE]: x86_64-pc-linux-gnu
sysconfig[MACHDEP]: linux
sysconfig[MULTIARCH]: x86_64-linux-gnu
sysconfig[OPT]: -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS_NODIST]: -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I../Include/internal
sysconfig[PY_STDMODULE_CFLAGS]: -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 -IObjects -IInclude -IPython -I. -I../Include
sysconfig[Py_DEBUG]: 0
sysconfig[Py_ENABLE_SHARED]: 0
sysconfig[SHELL]: /bin/sh
sysconfig[SOABI]: cpython-39-x86_64-linux-gnu
sysconfig[prefix]: /opt/python/3.9.0
test_socket.HAVE_SOCKET_ALG: True
test_socket.HAVE_SOCKET_BLUETOOTH: True
test_socket.HAVE_SOCKET_CAN: True
test_socket.HAVE_SOCKET_CAN_ISOTP: False
test_socket.HAVE_SOCKET_CAN_J1939: True
test_socket.HAVE_SOCKET_QIPCRTR: True
test_socket.HAVE_SOCKET_RDS: True
test_socket.HAVE_SOCKET_UDPLITE: True
test_socket.HAVE_SOCKET_VSOCK: False
test_support._is_gui_available: True
test_support.python_is_optimized: True
time.altzone: 21600
time.daylight: 0
time.get_clock_info(monotonic): namespace(implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, adjustable=False, resolution=1e-09)
time.get_clock_info(perf_counter): namespace(implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, adjustable=False, resolution=1e-09)
time.get_clock_info(process_time): namespace(implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, adjustable=False, resolution=1e-09)
time.get_clock_info(thread_time): namespace(implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, adjustable=False, resolution=1e-09)
time.get_clock_info(time): namespace(implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, adjustable=True, resolution=1e-09)
time.time: 1595880223.5866194
time.timezone: 21600
time.tzname: ('CST', 'CST')
tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.10
zlib.ZLIB_RUNTIME_VERSION: 1.2.11
zlib.ZLIB_VERSION: 1.2.11

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:10:48 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jul 2020 20:10:48 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595880648.56.0.116325237688.issue41405@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The lnotab warning is probably a bug in gcc 10

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:38:05 2020
From: report at bugs.python.org (Ian O'Shaughnessy)
Date: Mon, 27 Jul 2020 20:38:05 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595882285.39.0.63618671221.issue41389@roundup.psfhosted.org>


Ian O'Shaughnessy <ian_osh at apple.com> added the comment:

"Leak" was likely the wrong word.

It does appear problematic though.

The loop is using a fixed number of variables (yes, there are repeated dynamic allocations, but they fall out of scope with each iteration), only one of these variables occupies 1MB of ram (aside from the static variable).

The problem: There's only really one variable occupying 1MB of in-scope memory, yet the app's memory usage can/will exceed 1GB after extended use.

At the very least, this is confusing ? especially given the lack of user control to prevent it from happening once it's discovered as a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:39:52 2020
From: report at bugs.python.org (Howard A. Landman)
Date: Mon, 27 Jul 2020 20:39:52 +0000
Subject: [issue41335] free(): invalid pointer in list_ass_item() in Python
 3.7.3
In-Reply-To: <1595097501.98.0.660179014456.issue41335@roundup.psfhosted.org>
Message-ID: <1595882392.5.0.176230291157.issue41335@roundup.psfhosted.org>


Howard A. Landman <howard at riverrock.org> added the comment:

I'm running under 32-bit Raspbian, so let's assume the magic number is 13. There are only two places in my own code where the number 13 appears:

(1) My result_list is 14 items long, i.e. 0 to 13. Relevant code from qtd.py:
cum_results = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
...
while batches != 0:
    ...
    result_list = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
    for m in range(ITERS):
        ...
        result = tdc.measure(...)
        result_list[result] += 1
        ...
    for i in range(len(result_list)):
        cum_results[i] += result_list[i]

I notice that result_list is getting thrown away each cycle, and thus must be garbage-collected. I could try changing that and see if it has any effect.

(2) in the tdc7201 library, 13 occurs as a possible (error) result code from measure(). However several of the failing runs had zero errors of this class, which means the code with 13 in it never got executed even once. I am not using pin 13 of the RPi's header, so I never send that number to RPi.GPIO. GPIO13 is pin 33 of the header, and I am not using that pin either, so I don't think RPi.GPIO is translating one of my pin number arguments to 13 internally. (But I should check Broadcom Mode numbers.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41335>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:58:43 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 27 Jul 2020 20:58:43 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595883523.16.0.191706729253.issue41389@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

It's impossible for any implementation to know that cyclic trash _is_ trash without, in some way, traversing the object graph. This is expensive, so CPython (or any other language) does not incur that expense after every single decref that leaves a non-zero refcount (the one and only cheap clue that cyclic trash _may_ have just been created).

If you want/need synchronous behavior, avoid cycles. CPython's refcounting does dispose of trash the instant an object (not involved in a cycle) becomes trash. That behavior cannot be extended to cyclic trash short of (as above) running a cyclic gc pass extremely frequently.

I don't know of any language that guarantees all garbage will be collected "right away". Do you?  CPython does much more in that respect (due to primarily relying on refcounting) than most.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Mon Jul 27 17:36:15 2020
From: report at bugs.python.org (James Foster)
Date: Mon, 27 Jul 2020 21:36:15 +0000
Subject: [issue41414] AST for arguments shows extra element
Message-ID: <1595885775.67.0.745382264551.issue41414@roundup.psfhosted.org>


New submission from James Foster <python at jgfoster.net>:

https://docs.python.org/3.8/library/ast.html shows seven elements:
    arguments = (arg* posonlyargs, arg* args, arg? vararg, arg* kwonlyargs,
                 expr* kw_defaults, arg? kwarg, expr* defaults)

https://docs.python.org/3.7/library/ast.html shows six elements:
    arguments = (arg* args, arg? vararg, arg* kwonlyargs, expr* kw_defaults,
                 arg? kwarg, expr* defaults)

based on ast.c:1479 I believe that six is the proper number and that the first element ("arg* posonlyargs, ") is a duplicate of the second element ("arg* args, ") and should be removed.

----------
assignee: docs at python
components: Documentation
messages: 374425
nosy: docs at python, jgfoster
priority: normal
severity: normal
status: open
title: AST for arguments shows extra element
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41414>
_______________________________________

From report at bugs.python.org  Mon Jul 27 17:42:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jul 2020 21:42:41 +0000
Subject: [issue41414] AST for arguments shows extra element
In-Reply-To: <1595885775.67.0.745382264551.issue41414@roundup.psfhosted.org>
Message-ID: <1595886161.64.0.348574835309.issue41414@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

(arg* posonlyargs) is correct and was added to 3.8 as part of https://www.python.org/dev/peps/pep-0570/

----------
nosy: +pablogsal
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41414>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:19:59 2020
From: report at bugs.python.org (Ian O'Shaughnessy)
Date: Mon, 27 Jul 2020 22:19:59 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595888399.39.0.0560107589219.issue41389@roundup.psfhosted.org>


Ian O'Shaughnessy <ian_osh at apple.com> added the comment:

>I don't know of any language that guarantees all garbage will be collected "right away". Do you?

I'm not an expert in this domain, so, no. I am however attempting to find a way to mitigate this issue. Do you have any suggestions how I can avoid these memory spikes? Weak references? Calling gc.collect() on regular intervals doesn't seem to work consistently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:23:12 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Mon, 27 Jul 2020 22:23:12 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595888592.18.0.953439976845.issue41045@roundup.psfhosted.org>


Ama Aje My Fren <amaajemyfren at gmail.com> added the comment:

> then we can merge that one and close *this* issue.

I am looking at the pydoc issue now. It will take me more than an hour but I will figure it. Can that be under this issue also or (since you raised it as an OT) make that another issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:24:14 2020
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 27 Jul 2020 22:24:14 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595888654.35.0.985595002522.issue41405@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Is this a platform where 3.8 was working?

The curses test seems to think you have too many color-pairs defined, and this might well be part of a semi-compatible curses library. I guess I would add some output to the test showing how many (and which) color pairs it thinks there are.

The pwd complaint is correct, but seems like it is complaining about the interface between python and your OS.

The tkinter problem is really a failure to round a floating point, and I would be surprised if python had made changes there recently.  I would be slightly less surprised if something in the compile chain of tk for your system hard-coded a specific rounding format.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:29:29 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 22:29:29 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595888969.23.0.134410055946.issue41045@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I think your PR 21552 and any work you're doing on pydoc could go under the new issue 41411 that Ezio just opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:31:09 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jul 2020 22:31:09 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595889069.77.0.823542410815.issue41045@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 13efaec2e03288d7ff0ee643589c32bde6c6973c by amaajemyfren in branch 'master':
bpo-41045: Document debug feature of f-strings ('=') (GH-21509)
https://github.com/python/cpython/commit/13efaec2e03288d7ff0ee643589c32bde6c6973c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:32:18 2020
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 27 Jul 2020 22:32:18 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595889138.68.0.367361990769.issue41409@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

It may well have been intentional, as deques should normally be mutated only at the ends.  But Raymond did make changes to conform to the ABC, so this should probably be supported too.  Go ahead and include docstrings and/or discouraging it, though, except for i=0 and i=-1

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:32:22 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jul 2020 22:32:22 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595889142.28.0.684416897933.issue41045@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20784
pull_request: https://github.com/python/cpython/pull/21644

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:34:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 22:34:37 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595889277.48.0.845575438926.issue41045@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +20785
pull_request: https://github.com/python/cpython/pull/21645

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:41:33 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 22:41:33 +0000
Subject: [issue39959] Bug on multiprocessing.shared_memory
In-Reply-To: <1584128583.89.0.486447704556.issue39959@roundup.psfhosted.org>
Message-ID: <1595889693.65.0.729996312374.issue39959@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I declare this a duplicate of issue 38119.

----------
nosy: +gvanrossum
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> resource tracker destroys shared memory segments when other processes should still have valid access

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:45:29 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 22:45:29 +0000
Subject: [issue38119] resource tracker destroys shared memory segments when
 other processes should still have valid access
In-Reply-To: <1568217506.85.0.770661201111.issue38119@roundup.psfhosted.org>
Message-ID: <1595889929.72.0.00864523064749.issue38119@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Davin, could you merge one or the other of the PRs that fix this? Presumably also backport to 3.9 and 3.8 (but that's up to you and the release manager).

----------
nosy: +gvanrossum
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38119>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:01:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 23:01:56 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595890916.44.0.551466499694.issue41045@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset e962e3f65a086d9d3b848483fd01215d96ecc5f9 by Guido van Rossum in branch '3.9':
[3.9] bpo-41045: Document debug feature of f-strings ('=') (GH-21509) (GH-21645)
https://github.com/python/cpython/commit/e962e3f65a086d9d3b848483fd01215d96ecc5f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:06:29 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 23:06:29 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595891189.34.0.0280996785307.issue41045@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +20786
pull_request: https://github.com/python/cpython/pull/21647

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:12:07 2020
From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9gory_Starck?=)
Date: Mon, 27 Jul 2020 23:12:07 +0000
Subject: [issue41406] BufferedReader causes Popen.communicate losing the
 remaining output.
In-Reply-To: <1595838385.02.0.156491511968.issue41406@roundup.psfhosted.org>
Message-ID: <1595891527.71.0.735327786842.issue41406@roundup.psfhosted.org>


Gr?gory Starck <g.starck at gmail.com> added the comment:

also affecting 3.6

----------
nosy: +g.starck at gmail.com
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41406>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:15:18 2020
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 27 Jul 2020 23:15:18 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1595891718.03.0.525713300999.issue40841@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

The standard itself says that it only applies to content served over http; if the content is retrieved by ftp or from a file system, then you should trust that.  I don't notice that in the code you pointed to.

So maybe filetype is the right answer if the data isn't coming over the network?  For whatwg demonstration code, it is reasonable to assume that, but in python -- at a minimum, you should document the assumption prominently in the docs and docstring.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:14:57 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Jul 2020 23:14:57 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595891697.49.0.850822003402.issue41412@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I thought we already made it fail? (Checks) No we did not. Guess I misremembered that.

I'll fix this tomorrow. We need it, or else we'll be inundated with these reports for the entire life of 3.9.

----------
assignee:  -> steve.dower
priority: normal -> release blocker
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:21:48 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 23:21:48 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1595892108.58.0.891045448425.issue40841@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Whether the data was retrieved over a network has nothing to do with it.

There are complementary ways of guessing what data you are working with -- guess based on the filename extension or sniff based on the contents of the file (or downloaded data).

There are a zillion reasons why the filename could be a lie -- e.g. a user could pick the wrong extension, or rename a file, or a tool could save a file using the wrong extension or no extension at all. Then again sometimes the contents of the file might not be enough, e.g.
```
foo() // bar
```
is both valid Python and valid JavaScript. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:22:24 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 23:22:24 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595892144.07.0.616809352992.issue41045@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 3baff21f5bb8db7fa1c15788a8f82fa040a90d5d by Guido van Rossum in branch '3.8':
[3.8] bpo-41045: Document debug feature of f-strings ('=') (GH-21509) (#21647)
https://github.com/python/cpython/commit/3baff21f5bb8db7fa1c15788a8f82fa040a90d5d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:23:16 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jul 2020 23:23:16 +0000
Subject: [issue41045] f-string's "debug" feature is undocumented
In-Reply-To: <1592610792.76.0.722931750761.issue41045@roundup.psfhosted.org>
Message-ID: <1595892196.24.0.777309983131.issue41045@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks Ama Aje My Fren! You can transfer your other PR to a different bpo issue by editing the subject on GitHub.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41045>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:25:18 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jul 2020 23:25:18 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595892318.51.0.083013905809.issue41355@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
nosy: +pablogsal
nosy_count: 1.0 -> 2.0
pull_requests: +20787
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21648

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:33:53 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Mon, 27 Jul 2020 23:33:53 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595892833.7.0.467647514833.issue41405@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

I compiled and tested for same issues in 3.8.5 and they exist as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:34:16 2020
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 27 Jul 2020 23:34:16 +0000
Subject: [issue18280] Documentation is too personalized
In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za>
Message-ID: <1595892856.72.0.297358749153.issue18280@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

I won't speak of nroff or troff in particular, but many programs had trouble distinguishing the end of a sentence from an honorific abbreviation, such as Mr. Spock or Dr. Seuss.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18280>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:44:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jul 2020 23:44:17 +0000
Subject: [issue1175686] add "reload" function to IDLE
Message-ID: <1595893457.79.0.0562081853539.issue1175686@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1175686>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:44:35 2020
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 27 Jul 2020 23:44:35 +0000
Subject: [issue41407] Tricky behavior of builtin-function map
In-Reply-To: <1595844098.22.0.235301411882.issue41407@roundup.psfhosted.org>
Message-ID: <1595893475.8.0.353154265218.issue41407@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Why would you raise StopIteration if you didn't want to stop the nearest iteration loop?  I agree that the result of your sample code seems strange, but that is because it is strange code.

I agree with Steven D'Aprano that changing it would cause more pain than it would remove.

Unless it gets a lot more support by the first week of August, I recommend closing this request as rejected.

----------
nosy: +Jim.Jewett
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41407>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:59:15 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 27 Jul 2020 23:59:15 +0000
Subject: [issue41389] Garbage Collector Ignoring Some (Not All) Circular
 References of Identical Type
In-Reply-To: <1595620583.22.0.931401196723.issue41389@roundup.psfhosted.org>
Message-ID: <1595894355.79.0.304982579103.issue41389@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Well, this isn't a help desk ;-) You may want instead to detail your problem on, say, StackOverflow, or the general Python mailing list.

Please note that I don't know what your "problem" _is_:  you haven't said. You posted some numbers that didn't make sense to you, and made unwarranted extrapolations from those (for example, no, those numbers won't get worse if you let the program run a million times longer).

So you should spell out what the "real" problem is. This shows signs of being an "XY problem":

    http://xyproblem.info/
    
For example, now you say:

> Calling gc.collect() on regular intervals doesn't seem
> to work consistently

That's news to me. The code you posted shows quite different behavior when FORCE_GC is set.

But if it's true that calling gc.collect() regularly doesn't alleviate "the real problem" (whatever that may be!), then that shows the opposite of what you appear to be assuming: that Python's cyclic gc is the root of the cause. collect() _will_ reclaim every scrap of RAM that's actually trash at the time it's called. So if calling that doesn't help, the problem is almost certainly NOT that trash isn't getting reclaimed. Something else is the cause.

Examples: it's not actually trash. It is, and gc collects it, but is unable to return it to the C library from which the memory came. It is returned to the C library, but that in turn is unable to return the memory to the OS. It is returned to the OS, but the OS decides to leave its virtual address space mapped to the process for now.

Details not only matter, they _can_ be everything when dealing with the multiple layers of memory management on modern machines. Waiting for a "general insight" is probably futile here :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41389>
_______________________________________

From report at bugs.python.org  Mon Jul 27 20:36:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 00:36:45 +0000
Subject: [issue1721083] Add File - Reload
Message-ID: <1595896605.82.0.192751921153.issue1721083@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

All open files, up to the most recent 21 (and that could be increased) are in the recent file list.  Clicking on any name loads that file, unless it is already loaded.  The exception enforced in filelist.FileList.open, lines 29-32:

        if key in self.dict:
            edit = self.dict[key]
            edit.top.wakeup()
            return edit

I believe that we just need to ask, before the return, "Replace editor content with file content?" and if yes, call edit.io.loadfile(filename).

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1721083>
_______________________________________

From report at bugs.python.org  Mon Jul 27 20:56:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 00:56:04 +0000
Subject: [issue1721083] Add File - Reload
Message-ID: <1595897764.1.0.280967147308.issue1721083@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Recent edits to iomenu.IOBinding.loadfile were intended to preserve the option of reloading a non-empty editor.

----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1721083>
_______________________________________

From report at bugs.python.org  Mon Jul 27 21:04:42 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 28 Jul 2020 01:04:42 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1595898282.41.0.859143255116.issue41411@roundup.psfhosted.org>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +patch
pull_requests: +20788
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Mon Jul 27 21:09:43 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 01:09:43 +0000
Subject: [issue41000] IDLE: only allow single instance
In-Reply-To: <1592385738.41.0.899337100123.issue41000@roundup.psfhosted.org>
Message-ID: <1595898583.93.0.328697418731.issue41000@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We cannot prevent files being viewed and possibly modified by multiple programs and in general, should not.  I often open a file in more than one python version.  In any case, the proposed change would have a high chance on introducing bugs.  I just finished (I hope) repairing regressions in 3.8.4.  And 

There are, however, two real issues.  One is being able to reload a file, either because it has been changed on disk or because one want to abandon edits since the last save.  The other is detecting when a file might need to be reloaded because of external changes.

Reloading is the subject of #1721083 (from 2007).  I just outlined a easy fix there. The hard part is adding tests for the affected method.  You can do that if you want, and say so before I do it.

Detecting file changes like Notepad++ does would be a different issue.

#38946 is about Catalina making incompatible changes in Apple graphics so that tcl/tk does not work as well as it does in Mohave.

To me, the main blocker for multiple tabs is separating editor frames with a text widget from editor windows with a menu.  And the need to refactor the hierarchy of text frames.  And to stop duplicating per class objects as per instance objects.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41000>
_______________________________________

From report at bugs.python.org  Mon Jul 27 21:23:43 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 28 Jul 2020 01:23:43 +0000
Subject: [issue41374] socket.TCP_* no longer available with cygwin 3.1.6+
In-Reply-To: <1595490704.07.0.649120374256.issue41374@roundup.psfhosted.org>
Message-ID: <1595899423.76.0.678322880692.issue41374@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +20789
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21649

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41374>
_______________________________________

From report at bugs.python.org  Mon Jul 27 21:47:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 01:47:16 +0000
Subject: [issue41407] Tricky behavior of builtin-function map
In-Reply-To: <1595844098.22.0.235301411882.issue41407@roundup.psfhosted.org>
Message-ID: <1595900836.76.0.771518732867.issue41407@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Jim and Steven, so we'll mark this a closed.  

If you want to go forward, consider bringing this up on python-ideas.  If it gets a favorable reception, this can be re-opened.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41407>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:02:20 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:02:20 +0000
Subject: [issue41394] Document '_' in interpreter in shell tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595901740.24.0.558411011302.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
keywords: +patch
pull_requests: +20790
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21650

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:05:45 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:05:45 +0000
Subject: [issue41394] Document '_' in interpreter in shell tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595901945.26.0.802634210347.issue41394@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Submmited PR 21650. Should we also mention it in:
https://docs.python.org/3/tutorial/interpreter.html
or
https://docs.python.org/3/tutorial/appendix.html
?

(Matching the title of the issue)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:06:42 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:06:42 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595902002.85.0.120097398581.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
title: Document '_' in interpreter in shell tutorial -> Document '_' in interpreter tutorial

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:11:29 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Jul 2020 02:11:29 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595902289.08.0.844391695699.issue41394@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think it should be mentioned in https://docs.python.org/3/tutorial/appendix.html#tut-interac, since that's the link that https://docs.python.org/3/tutorial/interpreter.html#interactive-mode uses for it's "for more information" link. This seems like a "more information" kind of thing, to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:17:02 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:17:02 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595902622.99.0.349898583146.issue41394@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

If no one wants to work on it, I'll pick up that patch.
Should it be section 16.1.5? If not, what section should it fit into?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:26:01 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Jul 2020 02:26:01 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595903161.9.0.726852440502.issue41394@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think it should be in a new section. But I'd put it as a 16.1.2 and push the others down. It seems like a more important piece of information than shebangs and startup files in interactive mode. Or maybe I'd even put it first.

That said, I'm not terribly great at writing documentation, so you might want some other opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:27:33 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:27:33 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595903253.76.0.0130308693416.issue41394@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

I agree it's more important.
Working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:38:01 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:38:01 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595903881.02.0.251185063729.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests: +20792
pull_request: https://github.com/python/cpython/pull/21651

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:38:38 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 02:38:38 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595903918.95.0.637499979745.issue41394@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Submmited PR 21651.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:44:29 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 02:44:29 +0000
Subject: [issue41413] IDLE: exit at input() prompt is not complete
In-Reply-To: <1595872986.33.0.489785676605.issue41413@roundup.psfhosted.org>
Message-ID: <1595904269.59.0.561706167779.issue41413@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Simpler test.

Open IDLE Shell (only) from icon or (preferably) terminal.
>>> input()
   # Close IDLE without giving input with Window (X), File => exit, or Control/Command-Q.
Click OK in "Your program is still running" box (from PyShell)

On Windows, IDLE closes apparently cleanly, but Task Manager shows that (at least usually) the IDLE process moves from Apps to Background processes, with label 'Python x.y.z Shell', where it remains as an inaccessible 20 mb zombie until [End Task]ed.  This is not normal.

On macOS Mohave, the Shell window and IDLE part of the top menubar disappear, but the Apple part remains with the apple and program name entry ("IDLE" or "Python" depending on whether started from icon or Terminal).  I presume this is the equivalent of Python becoming a background process, except that Apple keeps a visible link to it.  If I start IDLE in Terminal with trailing &, there are initially two processes, and the first remains along with the Apple menu.

Under the IDLE/Python menu item, About and Preferences still bring up the corresponding dialogs, which worked as far as I tested.  This confirms that the IDLE process is still alive. A couple of times, Quit (Command-Q) worked to quit/crash python, and Segmentation Fault appeared in Terminal once.  Later, Quit did not work and I had to use (apple)=> Force Quit.

The trivial solution is to not close with input pending.  First, either hit Enter to let the user code run or end-of-file (default ^D) to kill it.  A corresponding patch could enforce this with a message to enter or kill before closing.

However, I believe the issue is that PyShell.readline uses a nested tk mainloop() as a control mechanism.  Four callbacks, including eof_callback, call quit() to exit the nested mainloop and finish readline.  But the callback has to finish and be pulled off the stack first.  Three of the callbacks return immediately after 'quit()'.  However, PyShell.close continues closing before readline continues.

When I replaced pyshell line  1016
        return EditorWindow.close(self)
with
        root.after(1, EditorWindow.close self)
the bug disappears.  The opens a time gap between PyShell.close and EditorWindow.close that allows readline to return '', signalling end-of-file.

This change also works on my Mac, except that I have to say 'yes' twice to close.
Irv, please try this replacement on your system.

----------
title: At prompt for input(), pressing Command q kills IDLE -> IDLE: exit at input() prompt is not complete

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________

From report at bugs.python.org  Mon Jul 27 23:26:36 2020
From: report at bugs.python.org (Kyle Evans)
Date: Tue, 28 Jul 2020 03:26:36 +0000
Subject: [issue41013] test_os.test_memfd_create() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1592434332.74.0.304039490213.issue41013@roundup.psfhosted.org>
Message-ID: <1595906796.11.0.497931496044.issue41013@roundup.psfhosted.org>


Kyle Evans <kevans at FreeBSD.org> added the comment:

Hey koobs,

Can you confirm that this is fine now after I implemented SHM_GROW_ON_WRITE?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41013>
_______________________________________

From report at bugs.python.org  Mon Jul 27 23:30:22 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 03:30:22 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595907022.74.0.9809183159.issue41409@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This was an intentional decision.  Deques designed for fast access at the end points. Also, pop() is a core deque operation that needs to be fast.  Altering its signature with an optional argument would slow it down.

Thank you for the suggestion, but we really shouldn't do this.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Mon Jul 27 23:32:55 2020
From: report at bugs.python.org (Martin Panter)
Date: Tue, 28 Jul 2020 03:32:55 +0000
Subject: [issue18861] Problems with recursive automatic exception chaining
In-Reply-To: <1377657727.9.0.627993776621.issue18861@psf.upfronthosting.co.za>
Message-ID: <1595907175.33.0.397717300121.issue18861@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18861>
_______________________________________

From report at bugs.python.org  Mon Jul 27 23:37:21 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 28 Jul 2020 03:37:21 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595907441.6.0.793064137987.issue41355@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm trying to give os.link() and follow_symlinks the benefit of the doubt, but the implementation just seems buggy to me. 

POSIX says that "[i]f path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself" [1]. In Linux, link() does not follow symlinks. One has to call linkat() with AT_SYMLINK_FOLLOW:

    AT_SYMLINK_FOLLOW (since Linux 2.6.18)
        By default, linkat(), does not dereference oldpath if it is a 
        symbolic link (like link()). The flag AT_SYMLINK_FOLLOW can be
        specified in flags to cause oldpath to be dereferenced if it is
        a symbolic link. 

The behavior is apparently the same in FreeBSD [2]. 

Thus the following implementation in os.link() seems buggy.

#ifdef HAVE_LINKAT
    if ((src_dir_fd != DEFAULT_DIR_FD) ||
        (dst_dir_fd != DEFAULT_DIR_FD) ||
        (!follow_symlinks))
        result = linkat(src_dir_fd, src->narrow,
            dst_dir_fd, dst->narrow,
            follow_symlinks ? AT_SYMLINK_FOLLOW : 0);
    else
#endif /* HAVE_LINKAT */

The only way that the value of follow_symlinks matters in Linux is if src_dir_fd or dst_dir_fd is used with a real file descriptor (i.e. not DEFAULT_DIR_FD, which is AT_FDCWD). Otherwise, the default True value of follow_symlinks is an outright lie. For example:

    >>> os.link in os.supports_follow_symlinks
    True
    >>> open('spam', 'w').close()
    >>> os.symlink('spam', 'spamlink1')
    >>> os.link('spamlink1', 'spamlink2')

spamlink2 was created as a hardlink to spamlink1, not its target, i.e. it's a symlink:
 
    >>> os.lstat('spamlink1').st_ino == os.lstat('spamlink2').st_ino
    True
    >>> os.readlink('spamlink2')
    'spam'

In contrast, if src_dir_fd is passed, then follow_symlinks=True is implemented as advertised (via AT_SYMLINK_FOLLOW):

    >>> fd = os.open('.', 0)
    >>> os.link('spamlink1', 'spamlink3', src_dir_fd=fd)

spamlink3 was created as a hardlink to spam, the target of spamlink1:
  
    >>> os.lstat('spam').st_ino == os.lstat('spamlink3').st_ino
    True

That the value of an unrelated parameter -- src_dir_fd -- changes the behavior of the follow_symlinks parameter is obviously a bug that should be addressed.

POSIX mandates that "[i]f both fd1 and fd2 have value AT_FDCWD, the behavior shall be identical to a call to link(), except that symbolic links shall be handled as specified by the value of flag". It's already using AT_FDCWD as a default value, so the implementation of os.link() should just unconditionally call linkat() if it's available. Then the value of follow_symlinks, true or false, will be honored, with or without passing src_dir_fd or dst_dir_fd.

That said, since os.link() hasn't been working as advertised, this change needs to be accompanied by changing the default value of follow_symlinks to False. That will retain the status quo behavior for most systems, except in the rare case that src_dir_fd or dst_dir_fd is used. If it isn't changed to False, then suddenly os.link() calls will start following symlinks, whereas prior to the change they did not because link() was being called instead of linkat(). 

--- 

In Windows, CreateHardLinkW [3] is incorrectly documented as following symlinks (i.e. "[i]f the path points to a symbolic link, the function creates a hard link to the target"). Actually, it opens the file to be hard-linked with the NTAPI option FILE_OPEN_REPARSE_POINT (same as WinAPI FILE_FLAG_OPEN_REPARSE_POINT). Thus no type of reparse point is followed, including symlinks.

---

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html
[2]: https://www.unix.com/man-page/FreeBSD/2/link
[3]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createhardlinkw

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 28 00:37:06 2020
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 28 Jul 2020 04:37:06 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1595911026.82.0.605890802933.issue31904@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Is it safe to say that there is an now intent to support VxWorks within the main tree, with Wind River agreeing to be primary support?

And this ticket has become a tracking ticket for the status on getting it there, small PR by small PR plus buildbot?

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Jul 28 00:39:59 2020
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 28 Jul 2020 04:39:59 +0000
Subject: [issue41415] duplicated signature of dataclass in help()
Message-ID: <1595911199.09.0.446200648486.issue41415@roundup.psfhosted.org>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

In [191]: import dataclasses, pydoc

In [192]: @dataclass
     ...: class C:
     ...:     pass
     ...:

In [193]: print(pydoc.render_doc(C))
Python Library Documentation: class C in module __main__

class C(builtins.object)
 |  C() -> None
 |
 |  C()
 |
 |  Methods defined here:
 |
 ....


It's duplicated because dataclass __doc__ defaults to signature:
 
In [195]: C.__doc__                                  
Out[195]: 'C()'

----------
components: Library (Lib)
messages: 374461
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: duplicated signature of dataclass in help()
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41415>
_______________________________________

From report at bugs.python.org  Tue Jul 28 00:41:25 2020
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 28 Jul 2020 04:41:25 +0000
Subject: [issue41415] duplicated signature of dataclass in help()
In-Reply-To: <1595911199.09.0.446200648486.issue41415@roundup.psfhosted.org>
Message-ID: <1595911285.2.0.301920329118.issue41415@roundup.psfhosted.org>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +20793
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21652

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41415>
_______________________________________

From report at bugs.python.org  Tue Jul 28 00:50:38 2020
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 28 Jul 2020 04:50:38 +0000
Subject: [issue41391] Make test_unicodedata pass when running without network
In-Reply-To: <1595672814.77.0.412111562602.issue41391@roundup.psfhosted.org>
Message-ID: <1595911838.86.0.471815319706.issue41391@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Looks Good To Me

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41391>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:00:07 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 28 Jul 2020 05:00:07 +0000
Subject: [issue41013] test_os.test_memfd_create() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1592434332.74.0.304039490213.issue41013@roundup.psfhosted.org>
Message-ID: <1595912407.94.0.256146526687.issue41013@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

@Kyle Yes, msg373597 freebsd CURRENT buildbot passes, but freebsd 12/stable does not (cannot, since stable/12 wont get the syscall)

That means the Python memfd functions and tests need to account for this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41013>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:11:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Jul 2020 05:11:43 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <1595913103.7.0.536408423147.issue19016@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:14:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 05:14:44 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595913284.59.0.584861303055.issue41409@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, the relationship between a concrete class and an ABC is normative with respect to core capabilities but isn't 100% strict.  Concrete classes can vary in small respects when it makes sense.  For example, the __or__ and __and__ methods for collections.Set will accept any iterable, but the concrete does not.  

We use the Liskov substitution principle as a guide, not as a law.  In a number of cases, we choose practicality-beats-purity and allow subclasses to differ in ways than their parents.  Counter() doesn't support fromkeys().  OrderedDict.popitem() has different signature than dict.popitem().

Hope that insight was helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:33:28 2020
From: report at bugs.python.org (Dmytro Litvinov)
Date: Tue, 28 Jul 2020 05:33:28 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595914408.52.0.617285337384.issue41328@roundup.psfhosted.org>


Change by Dmytro Litvinov <litvinov.dmytro.it at gmail.com>:


----------
keywords: +patch
pull_requests: +20794
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21653

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:41:27 2020
From: report at bugs.python.org (Dmytro Litvinov)
Date: Tue, 28 Jul 2020 05:41:27 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595914887.61.0.944536308532.issue41328@roundup.psfhosted.org>


Dmytro Litvinov <litvinov.dmytro.it at gmail.com> added the comment:

Hi Terry,

Seems like link to Academic Free License v. 2.1(https://www.python.org/psf/contrib/) does not work. That link is mentioned at https://www.python.org/psf/contrib/ that you gave me.

Also, I have signed CLA before submitting PR as you wrote. From CLA bot at GitHub I see that I need to wait at least one business day. Should I wait for approval and then I could ping you one more time for reviewing patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:47:14 2020
From: report at bugs.python.org (Martin Panter)
Date: Tue, 28 Jul 2020 05:47:14 +0000
Subject: [issue41345] Remote end closed connection without response
In-Reply-To: <1595245426.33.0.812684814237.issue41345@roundup.psfhosted.org>
Message-ID: <1595915234.81.0.940515924804.issue41345@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Previous report about Requests to the Python bug tracker: Issue 33620.

I suspect this is an unavoidable race condition with trying a POST (or other non-idempotent) request on an idle HTTP connection. I think it has to be up to the higher-level application or user to decide if it is safe to retry a POST request. Otherwise you risk e.g. accidentally ordering two pizzas because the server received two POST requests but something interfered with the response of the first response. On the other hand, I noticed some browsers seem to automatically retry a POST once if it is interrupted, which makes me uneasy.

A concrete example of the problem is a firmware upload that triggers a reboot. If the reboot is too quick and prevents the POST response being sent, I found that a web browser will repeat the firmware upload once more after my firmware boots up again.

If it is not safe to retry the POST request, other options would be to avoid the server thinking the connection is stale:

* always do the POST request on a fresh HTTP connection
* "ping" the connection with a dummy request (e.g. OPTIONS, HEAD, or GET) immediately before the POST request

Another option that comes to mind is to try using the 100 Continue mechanism, but this is not a general solution and depends on the application.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41345>
_______________________________________

From report at bugs.python.org  Tue Jul 28 01:56:06 2020
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 28 Jul 2020 05:56:06 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1595892108.58.0.891045448425.issue40841@roundup.psfhosted.org>
Message-ID: <CA+OGgf6wzprMWPiKqwUUGbM-WU7EQDcgbvYUgTqeK7-PyGDmsw@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

There are a zillion reasons a filename could be wrong -- but the standard
says to trust the filesystem.  So if it sniffs based on contents, it isn't
quite following the standard.  It is probably still a useful tool, but it
won't be the One Right Way, and it isn't even clear that it should replace
current heuristics.

On Mon, Jul 27, 2020 at 7:22 PM Guido van Rossum <report at bugs.python.org>
wrote:

>
> Guido van Rossum <guido at python.org> added the comment:
>
> Whether the data was retrieved over a network has nothing to do with it.
>
> There are complementary ways of guessing what data you are working with --
> guess based on the filename extension or sniff based on the contents of the
> file (or downloaded data).
>
> There are a zillion reasons why the filename could be a lie -- e.g. a user
> could pick the wrong extension, or rename a file, or a tool could save a
> file using the wrong extension or no extension at all. Then again sometimes
> the contents of the file might not be enough, e.g.
> ```
> foo() // bar
> ```
> is both valid Python and valid JavaScript. :-)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40841>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Tue Jul 28 02:03:18 2020
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 28 Jul 2020 06:03:18 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595916198.56.0.837361353417.issue41405@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Then I suspect they also exist in even earlier versions, and are actually tied to your development setup.  That should still be fixed, but it is probably not in Python's own code.  It might be in python's build process, which is still on us.  Or it might be in your distribution, or in a dependency like Tk, or in your personal C compiler or setup.

Could you look to see what your system's actual passwd file says, and how tcl rounds outside of python, and how many color pairs your curses supports or has?

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Tue Jul 28 02:16:51 2020
From: report at bugs.python.org (Peixing Xin)
Date: Tue, 28 Jul 2020 06:16:51 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1595917011.95.0.83684468491.issue31904@roundup.psfhosted.org>


Peixing Xin <peixing.xin at windriver.com> added the comment:

@Jim.Jewett  Yes. We have got most modules passed testing locally. Now we want to get the patches upstream. So VxWorks platform can be officially supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Jul 28 02:34:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 06:34:53 +0000
Subject: [issue41416] Restore default implementation of __ne__ in mixins Set
 and Mapping
Message-ID: <1595918093.33.0.049225231479.issue41416@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

According to the documentation [1] abstract classes collections.abc.Set and collections.abc.Mapping provide mixin method __ne__. But implementations of __ne__ in these classes were removed in 3.4 (see issue21408), so the default implementation is inherited from object. The reason is that it works better with classes which override __ne__ to return non-boolean, e.g. NumPy, SymPy and sqlalchemy classes. Previously the != operator falled back to other__eq__(), now it falls back to other__ne__().

[1] https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes

But now we have a discrepancy between the decomentation and the code. According to the documentation, if we have a class which inherits from both Set and int, in that order, the __ne__ method should be inherited from class Set instead of class int. But currently it is inherited from int.

>>> import collections.abc
>>> class A(collections.abc.Set, int): pass
... 
>>> A.__ne__
<slot wrapper '__ne__' of 'int' objects>

One way to solve this -- remove __ne__ from lists of mixin methods (see issue41400). Other way -- add the __ne__ implementations which are identical to the default implementation but has preference in the inheritance. I prefer the latter.

----------
components: Library (Lib)
messages: 374470
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Restore default implementation of __ne__ in mixins Set and Mapping
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41416>
_______________________________________

From report at bugs.python.org  Tue Jul 28 02:36:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 06:36:22 +0000
Subject: [issue41416] Restore default implementation of __ne__ in mixins Set
 and Mapping
In-Reply-To: <1595918093.33.0.049225231479.issue41416@roundup.psfhosted.org>
Message-ID: <1595918182.33.0.653957114388.issue41416@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +20795
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21628

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41416>
_______________________________________

From report at bugs.python.org  Tue Jul 28 02:36:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 06:36:55 +0000
Subject: [issue41416] Restore default implementation of __ne__ in mixins Set
 and Mapping
In-Reply-To: <1595918093.33.0.049225231479.issue41416@roundup.psfhosted.org>
Message-ID: <1595918215.32.0.487488165551.issue41416@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -20795

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41416>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:07:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 07:07:29 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1595920049.84.0.0756220007503.issue40841@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think that both functions for detecting file type, by name and by content, are useful in different circumstances. We have similar more specific detection functions sndhdr and imghdr.

But I am not sure whether it should be a part of the mimetypes module or separate module. Should it use sndhdr and imghdr modules for audio and image types? Should it be a wrapper to the libmagic library (https://linux.die.net/man/3/libmagic) or reimplement it in Python?

If we add the code for detecting the file type based on algorithms used in browsers, should not we add also the code for detecting the text encoding based on other algorithms used in browsers, or it is too much?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:11:50 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 07:11:50 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595920310.69.0.0968205556319.issue41409@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If deque does not fully support the MutableSequence interface, should not it be un-regitered as MutableSequence? Maybe we need other abstract class which would be parent of MutableSequence and deque?

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:31:52 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2020 07:31:52 +0000
Subject: [issue36788] Add clamp() function to builtins
In-Reply-To: <1556920200.45.0.0628062537563.issue36788@roundup.psfhosted.org>
Message-ID: <1595921512.67.0.866442839543.issue36788@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

#41408 was closed as a duplicate of this issue

See also the recent discussion on python-ideas at https://mail.python.org/archives/list/python-ideas at python.org/thread/KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS/#KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS

That discussion has petered out without a clear consensus. The next step would likely be for an interested party to put together a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36788>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:32:49 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2020 07:32:49 +0000
Subject: [issue41408] Add a `clamp` function to the `math` module
In-Reply-To: <1595852913.43.0.233033170193.issue41408@roundup.psfhosted.org>
Message-ID: <1595921569.95.0.442584524575.issue41408@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution: rejected -> duplicate
superseder:  -> Add clamp() function to builtins

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41408>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:35:51 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2020 07:35:51 +0000
Subject: [issue36788] Add clamp() function to builtins
In-Reply-To: <1556920200.45.0.0628062537563.issue36788@roundup.psfhosted.org>
Message-ID: <1595921751.97.0.493973482367.issue36788@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another python-ideas thread, from 2016: https://mail.python.org/archives/list/python-ideas at python.org/thread/EHZAXE4P2VOT3CE4H6SNDPDASW7H2CGS/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36788>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:43:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 28 Jul 2020 07:43:13 +0000
Subject: [issue41395] pickle and pickletools cli interface doesn't close input
 and output file.
In-Reply-To: <1595686330.63.0.838691465271.issue41395@roundup.psfhosted.org>
Message-ID: <1595922193.66.0.758252673661.issue41395@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41395>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:48:05 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Tue, 28 Jul 2020 07:48:05 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1595922485.34.0.487741915848.issue41411@roundup.psfhosted.org>


Ama Aje My Fren <amaajemyfren at gmail.com> added the comment:

Hi Ezio,

Would you see this being resolved in part by a HOWTO document?

----------
nosy: +amaajemyfren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:55:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 07:55:02 +0000
Subject: [issue41395] pickle and pickletools cli interface doesn't close input
 and output file.
In-Reply-To: <1595686330.63.0.838691465271.issue41395@roundup.psfhosted.org>
Message-ID: <1595922902.76.0.59984895496.issue41395@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41395>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:59:37 2020
From: report at bugs.python.org (=?utf-8?b?SmFuIMSMZcWhcGl2bw==?=)
Date: Tue, 28 Jul 2020 07:59:37 +0000
Subject: [issue41417] SyntaxError: assignment expression within assert
Message-ID: <1595923177.97.0.806397891633.issue41417@roundup.psfhosted.org>


New submission from Jan ?e?pivo <jan.cespivo at gmail.com>:

Hi,

it should be useful if assignment expression works within assertion.

For example (real use-case in tests):

assert r := re.match(r"result is (\d+)", tested_text)
assert int(r.group(1)) == expected_number

I haven't found a mention about assertions in https://www.python.org/dev/peps/pep-0572/ so it isn't technically a bug but it might be omission (?).

Thx!

----------
components: Interpreter Core
messages: 374476
nosy: jan.cespivo
priority: normal
severity: normal
status: open
title: SyntaxError: assignment expression within assert
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41417>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:03:01 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 08:03:01 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595923381.09.0.0333147359868.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests: +20796
pull_request: https://github.com/python/cpython/pull/21654

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:02:24 2020
From: report at bugs.python.org (karl)
Date: Tue, 28 Jul 2020 08:02:24 +0000
Subject: [issue36661] Missing dataclass decorator import in dataclasses module
 docs
In-Reply-To: <1555616208.44.0.536731608649.issue36661@roundup.psfhosted.org>
Message-ID: <1595923344.58.0.663643518535.issue36661@roundup.psfhosted.org>


karl <karl+pythonbugs at la-grange.net> added the comment:

This should be closed. The PR has been merged and the doc is now up to date.

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36661>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:10:23 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Jul 2020 08:10:23 +0000
Subject: [issue41417] SyntaxError: assignment expression within assert
In-Reply-To: <1595923177.97.0.806397891633.issue41417@roundup.psfhosted.org>
Message-ID: <1595923823.11.0.147644674554.issue41417@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't know if this limitation is intentional, but not that you can use an assignment expression when you enclose the expression with parenthesis:

>>> assert (a:=1)
>>> a
1
>>>

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41417>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:14:35 2020
From: report at bugs.python.org (=?utf-8?b?SmFuIMSMZcWhcGl2bw==?=)
Date: Tue, 28 Jul 2020 08:14:35 +0000
Subject: [issue41417] SyntaxError: assignment expression within assert
In-Reply-To: <1595923177.97.0.806397891633.issue41417@roundup.psfhosted.org>
Message-ID: <1595924075.23.0.493856376022.issue41417@roundup.psfhosted.org>


Jan ?e?pivo <jan.cespivo at gmail.com> added the comment:

Hi Ronald,

thank you. It works! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41417>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:14:46 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Jul 2020 08:14:46 +0000
Subject: [issue41417] SyntaxError: assignment expression within assert
In-Reply-To: <1595923177.97.0.806397891633.issue41417@roundup.psfhosted.org>
Message-ID: <1595924086.97.0.853741441819.issue41417@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41417>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:41:12 2020
From: report at bugs.python.org (karl)
Date: Tue, 28 Jul 2020 08:41:12 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1595925672.3.0.01595106854.issue40236@roundup.psfhosted.org>


karl <karl+pythonbugs at la-grange.net> added the comment:

Same on macOS 10.15.6 (19G73)


Python 3.8.3 (v3.8.3:6f8c8320e9, May 13 2020, 16:29:34) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.strptime("2024-0-3 00:00:00", "%Y-%W-%w %H:%M:%S")
datetime.datetime(2024, 1, 3, 0, 0)
>>> datetime.datetime.strptime("2024-1-3 00:00:00", "%Y-%W-%w %H:%M:%S")
datetime.datetime(2024, 1, 3, 0, 0)


Also 
https://pubs.opengroup.org/onlinepubs/007908799/xsh/strptime.html

note that iso8601 doesn't have this issue.
%V - ISO 8601 week of the year as a decimal number [01, 53].
https://en.wikipedia.org/wiki/ISO_week_date

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:42:04 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 28 Jul 2020 08:42:04 +0000
Subject: [issue35328] Set a environment variable for venv prompt
In-Reply-To: <1543335149.71.0.788709270274.issue35328@psf.upfronthosting.co.za>
Message-ID: <1595925724.9.0.339129003085.issue35328@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset c82dda1e08c4b74ca24f88d6a549d93108c319cf by Zackery Spytz in branch 'master':
bpo-35328: Set VIRTUAL_ENV_PROMPT at venv activation (GH-21587)
https://github.com/python/cpython/commit/c82dda1e08c4b74ca24f88d6a549d93108c319cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:57:05 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 08:57:05 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595926625.26.0.338289026025.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests:  -20792

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Tue Jul 28 05:15:44 2020
From: report at bugs.python.org (Heyi Tang)
Date: Tue, 28 Jul 2020 09:15:44 +0000
Subject: [issue41318] Better error message of "Cannot recover from stack
 overflow."
In-Reply-To: <1594957263.52.0.457195944754.issue41318@roundup.psfhosted.org>
Message-ID: <1595927744.66.0.708235582379.issue41318@roundup.psfhosted.org>


Change by Heyi Tang <tangheyi.09 at gmail.com>:


----------
keywords: +patch
pull_requests: +20798
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21655

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41318>
_______________________________________

From report at bugs.python.org  Tue Jul 28 06:18:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 10:18:58 +0000
Subject: [issue41417] SyntaxError: assignment expression within assert
In-Reply-To: <1595923177.97.0.806397891633.issue41417@roundup.psfhosted.org>
Message-ID: <1595931538.78.0.929640470195.issue41417@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is a duplicate of issue39909.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Assignment expression in assert causes SyntaxError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41417>
_______________________________________

From report at bugs.python.org  Tue Jul 28 06:43:25 2020
From: report at bugs.python.org (Akuli)
Date: Tue, 28 Jul 2020 10:43:25 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595933005.69.0.0227369195926.issue41409@roundup.psfhosted.org>


Akuli <akuviljanen17 at gmail.com> added the comment:

I don't think it's very common to write code that needs to work with any MutableSequence but not with any Sequence. I think that's the only situation where missing support for deque.pop(index) is a problem.

Maybe deque should be a Sequence but not a MutableSequence. Or maybe there should be a way to say "MutableSequence does not require support for .pop(index) even though you get it by inheriting from MutableSequence".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:05:35 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:05:35 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595934335.48.0.930053666607.issue40948@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Assuming it fits, I'm going to update the 3.9+ post-install message to this (assume the HTML renders normally). Any comments?


New to Python? Start with the &lt;a href="https://docs.python.org/[ShortVersion]/tutorial/index.html"&gt;online tutorial&lt;/a&gt; and &lt;a href="https://docs.python.org/[ShortVersion]/index.html"&gt;documentation&lt;/a&gt;.

At your terminal, type "py" to launch Python, or search for Python in your Start menu.

See &lt;a href="https://docs.python.org/[ShortVersion]/whatsnew/[ShortVersion].html"&gt;what's new&lt;/a&gt; in this release.

Special thanks to Mark Hammond, without whose years of freely shared Windows expertise, Python for Windows would still be Python for DOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:06:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Jul 2020 11:06:41 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595934401.52.0.280583217565.issue41355@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> That said, since os.link() hasn't been working as advertised, this change needs to be accompanied by changing the default value of follow_symlinks to False. That will retain the status quo behavior for most systems, except in the rare case that src_dir_fd or dst_dir_fd is used. If it isn't changed to False, then suddenly os.link() calls will start following symlinks, whereas prior to the change they did not because link() was being called instead of linkat(). 


Isn't that a backwards-incompatible change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:27:34 2020
From: report at bugs.python.org (karl)
Date: Tue, 28 Jul 2020 11:27:34 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1595935654.15.0.373775044195.issue40236@roundup.psfhosted.org>


karl <karl+pythonbugs at la-grange.net> added the comment:

Also this.

>>> import datetime
>>> d0 = datetime.datetime.strptime("2024-0-3 00:00:00", "%Y-%W-%w %H:%M:%S")
>>> d0.strftime("%Y-%W-%w %H:%M:%S")
'2024-01-3 00:00:00'
>>> d1 = datetime.datetime.strptime("2024-1-3 00:00:00", "%Y-%W-%w %H:%M:%S")
>>> d1.strftime("%Y-%W-%w %H:%M:%S")
'2024-01-3 00:00:00'
>>> d2301 = datetime.datetime.strptime("2023-0-1 00:00:00", "%Y-%W-%w %H:%M:%S")
>>> d2311 = datetime.datetime.strptime("2023-1-1 00:00:00", "%Y-%W-%w %H:%M:%S")
>>> d2301
datetime.datetime(2022, 12, 26, 0, 0)
>>> d2311
datetime.datetime(2023, 1, 2, 0, 0)
>>> d2311.strftime("%Y-%W-%w %H:%M:%S")
'2023-01-1 00:00:00'
>>> d2301.strftime("%Y-%W-%w %H:%M:%S")
'2022-52-1 00:00:00'


Week 0 2023 became Week 52 2022 (which is correct but might lead to surprises)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:41:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:41:36 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595936496.5.0.547598503858.issue40948@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Added a screenshot, after tweaking the spacing just a little.

----------
Added file: https://bugs.python.org/file49343/postinstall.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:44:59 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:44:59 +0000
Subject: [issue40947] Replace PLATLIBDIR macro with config->platlibdir
In-Reply-To: <1591870006.36.0.733271971459.issue40947@roundup.psfhosted.org>
Message-ID: <1595936699.49.0.917966014998.issue40947@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower
nosy_count: 2.0 -> 3.0
pull_requests: +20800
pull_request: https://github.com/python/cpython/pull/21656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40947>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:44:59 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:44:59 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595936699.36.0.377457265366.issue41412@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20799
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:45:28 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:45:28 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595936728.8.0.401819370424.issue40948@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +20801
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:45:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:45:49 +0000
Subject: [issue40947] Replace PLATLIBDIR macro with config->platlibdir
In-Reply-To: <1591870006.36.0.733271971459.issue40947@roundup.psfhosted.org>
Message-ID: <1595936749.88.0.897958309134.issue40947@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests:  -20800

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40947>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:46:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 11:46:03 +0000
Subject: [issue40947] Replace PLATLIBDIR macro with config->platlibdir
In-Reply-To: <1591870006.36.0.733271971459.issue40947@roundup.psfhosted.org>
Message-ID: <1595936763.07.0.737598256238.issue40947@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy:  -steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40947>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:48:26 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 28 Jul 2020 11:48:26 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595936906.45.0.314447901632.issue41355@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Isn't that a backwards-incompatible change?

So, do you think it should just be documented that follow_symlinks is effectively ignored with os.link() on most platforms that claim to support it, unless either src_dir_fd or dst_dir_fd is used? I'd rather it was fixed to behave consistently in 3.10, even if it's backwards incompatible with some use cases on some platforms. I think for most use cases, it's just called without arguments as os.link(src, dst), in which case on most platforms switching the default to follow_symlinks=False will preserve the existing and expected behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 28 07:55:15 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 11:55:15 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595937315.85.0.586278885076.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests: +20802
pull_request: https://github.com/python/cpython/pull/21657

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Tue Jul 28 08:04:31 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 28 Jul 2020 12:04:31 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1595937871.34.0.962385424752.issue41411@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

HOWTOs are generally used to explain how to accomplish a certain task, so I'm not sure if they are a good fit for this situation.

In the list of proposed solutions in my first message, 1-3 should be quite easy to implement.  This leaves us with 4-5.

To summarize what we already have (let me know if I missed anything):
* string.rst[0] (the string module):
    String constants (string constants)
    Custom String Formatting (string.Formatter)
    Format String Syntax (explains the syntax of {...})
        Format Specification Mini-Language
        Format examples
    Template strings (string.Template)
    Helper functions (string.capwords)
* stdtypes.rst[1] (about Python builtin types):
  Text Sequence Type ? str (short intro about str)
    String Methods (all the str.* methods)
    printf-style String Formatting (old %-formatting)
* introduction.rst[2] (the string section in the tutorial)
* lexical_analysis.rst[3]
  String and Bytes literals
  String literal concatenation
  Formatted string literals

The lexical analysis is probably fine as is.  The introduction in the tutorial should mention f-strings, include a couple of examples, and link to the documentation for more.  The stdtypes page is already quite long and crowded, so I'm wary about adding more stuff in there.  So, unless we add a separate page somewhere, the string page seems the best candidate, even if technically it should be about the string module.

On top of items 1-3 of my previous message, to solve 4-5 I suggest to:
1) move the printf-style formatting section to string.rst;
2) add a section about f-strings under Format String Syntax in string.rst, focusing on differences and caveats that are unique to f-strings;
3) add some f-string-specific examples after the format examples
4) mention f-string in the string section of the tutorial, and in the text sequence type section of stdtypes.rst;

The string.rst page could then look something like:
    String constants (string constants)
    Custom String Formatting (string.Formatter)
    Format String Syntax (explains the syntax of {...})
        Format Specification Mini-Language
        Format examples
        f-strings
        f-strings examples
    printf-style String Formatting (old %-formatting)
    Template strings (string.Template)
    Helper functions (string.capwords)

This should consolidate all the docs in two places: string.rst and lexical_analysis.rst (they have a different target, so the separation is ok).  All other places can then refer to this.  Once this is done, we can still decide to move these out of string.rst.

[0]: https://docs.python.org/3/library/string.html
[1]: https://docs.python.org/3/library/stdtypes.html#textseq
[2]: https://docs.python.org/3/tutorial/introduction.html#strings
[3]: https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Tue Jul 28 08:13:27 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 28 Jul 2020 12:13:27 +0000
Subject: [issue41394] Document '_' in interpreter tutorial
In-Reply-To: <1595681668.98.0.691710937609.issue41394@roundup.psfhosted.org>
Message-ID: <1595938407.87.0.554772775655.issue41394@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
pull_requests:  -20790

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41394>
_______________________________________

From report at bugs.python.org  Tue Jul 28 08:33:37 2020
From: report at bugs.python.org (Mats Wichmann)
Date: Tue, 28 Jul 2020 12:33:37 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595939617.82.0.217369756137.issue40948@roundup.psfhosted.org>


Mats Wichmann <mats at python.org> added the comment:

I still think there ought to be some pointer to https://docs.python.org/3/using/windows.html in there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 09:35:40 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 13:35:40 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595943340.59.0.644595722254.issue40948@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I changed the middle paragraph to this:

See &lt;a href="https://docs.python.org/[ShortVersion]/whatsnew/[ShortVersion].html"&gt;what's new&lt;/a&gt; in this release, or find more info about &lt;a href="https://docs.python.org/[ShortVersion]/using/windows.html"&gt;using Python on Windows&lt;/a&gt;.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:08:34 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Tue, 28 Jul 2020 14:08:34 +0000
Subject: [issue41418] Add snake game to tools/demo!
Message-ID: <1595945314.49.0.985793426755.issue41418@roundup.psfhosted.org>


New submission from Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:

Its simple snake game for beginners! It based on simple algorithm! If you know! And it must be on python/cpython repo! Cause, I made python (snake) game with Python Programming Language xD (maybe not funny)!

We love python as much as you do! Yea!

----------
components: Tkinter
files: snake.py
messages: 374492
nosy: Ehsonjon Gadoev
priority: normal
severity: normal
status: open
title: Add snake game to tools/demo!
versions: Python 3.8
Added file: https://bugs.python.org/file49344/snake.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41418>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:11:40 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Tue, 28 Jul 2020 14:11:40 +0000
Subject: [issue41418] Add snake game to tools/demo!
In-Reply-To: <1595945314.49.0.985793426755.issue41418@roundup.psfhosted.org>
Message-ID: <1595945500.51.0.632357890607.issue41418@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
keywords: +patch
pull_requests: +20803
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21658

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41418>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:12:56 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Tue, 28 Jul 2020 14:12:56 +0000
Subject: [issue41418] Add snake game to tools/demo!
In-Reply-To: <1595945314.49.0.985793426755.issue41418@roundup.psfhosted.org>
Message-ID: <1595945576.61.0.658241691189.issue41418@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
hgrepos: +390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41418>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:15:40 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Tue, 28 Jul 2020 14:15:40 +0000
Subject: [issue41418] GH-21658: Add snake game to tools/demo!
In-Reply-To: <1595945314.49.0.985793426755.issue41418@roundup.psfhosted.org>
Message-ID: <1595945740.71.0.934255874282.issue41418@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
title: Add snake game to tools/demo! -> GH-21658: Add snake game to tools/demo!

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41418>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:44:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 14:44:05 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595947445.31.0.894165429158.issue41409@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> If deque does not fully support the MutableSequence interface,
> should not it be un-regitered as MutableSequence?

You could unregister it, but for such a minor variance, it isn't worth it.  We're not unregistering sets and frozenset from Set even though there are minor variances in the operators. 

The ABCs are quite limited in what they do. The underlying machinery is mostly about determining whether a method is present or not.  Concrete classes are free to override, extend or raise NotImplemented.  For example, a Counter is still a mapping even though fromkeys() raises NotImplemented and update() has different semantics than Mapping.  

Jelle has already adapted TypeShed to match the concrete class, so no actual user issue remains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:49:10 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 14:49:10 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595947750.58.0.486707835498.issue41328@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20805
pull_request: https://github.com/python/cpython/pull/21659

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:48:39 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 14:48:39 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595947719.44.0.46671161681.issue41328@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5e3826785dcc64f8e1a8a7bde11b88fbb40943be by Dmytro Litvinov in branch 'master':
bpo-41328: Replace mention of Hudson CI with Travis CI and AppVeyor (GH-21653)
https://github.com/python/cpython/commit/5e3826785dcc64f8e1a8a7bde11b88fbb40943be


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:49:17 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 14:49:17 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595947757.98.0.871317403745.issue41328@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20806
pull_request: https://github.com/python/cpython/pull/21660

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:52:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 14:52:09 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595947929.53.0.770203628502.issue41328@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:51:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 14:51:55 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595947915.49.0.113288067234.issue41328@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Can you file a separate bug report for the license link? We may need to review that with the lawyer, to see if we can use AFL 3.0, since AFL 2.1 seems obsolete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:54:47 2020
From: report at bugs.python.org (Christopher Harrison)
Date: Tue, 28 Jul 2020 14:54:47 +0000
Subject: [issue41419] Path.mkdir and os.mkdir don't respect setgid if its
 parent is g-s
Message-ID: <1595948087.76.0.888842556227.issue41419@roundup.psfhosted.org>


New submission from Christopher Harrison <ch12 at sanger.ac.uk>:

The setgid bit is not set when creating a directory, even when explicitly specified in the mode argument, when its containing directory doesn't have its own setgid bit set. When the parent does have the setgid bit, it works as expected.

Steps to reproduce:

1. Outside of Python, create a working directory with mode 0770, such that:

   >>> from pathlib import Path
   >>> oct(Path().stat().st_mode)
   '0o40770'

2. Set the umask to 0, to be sure it's not a masking issue:

   >>> import os
   >>> _ = os.umask(0)

3. Create a subdirectory with mode ug+rwx,g+s (2770):

   >>> (test := Path("test")).mkdir(0o2770)
   >>> oct(test.stat().st_mode)
   '0o40770'

   Notice that setgid is not respected.

4. Set setgid to the working directory:

   >>> Path().chmod(0o2770)
   >>> oct(Path().stat().st_mode)
   '0o42770'

   This works as expected.

5. Create another subdirectory with mode ug+rwx,g+s:

   >>> (test2 := Path("test2")).mkdir(0o2770)
   >>> oct(test2.stat().st_mode)
   '0o42770'

   The setgid bit of the new directory is now correctly set.

This also affects os.mkdir.

I have only tested this under Python 3.8.2 and 3.8.3 on a POSIX filesystem. (I assume it's not relevant to non-POSIX filesystems.)

----------
components: Library (Lib)
messages: 374496
nosy: Xophmeister
priority: normal
severity: normal
status: open
title: Path.mkdir and os.mkdir don't respect setgid if its parent is g-s
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41419>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:56:04 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 14:56:04 +0000
Subject: [issue41416] Restore default implementation of __ne__ in mixins Set
 and Mapping
In-Reply-To: <1595918093.33.0.049225231479.issue41416@roundup.psfhosted.org>
Message-ID: <1595948164.56.0.0392666688679.issue41416@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> if we have a class which inherits from both Set and int

This really seems like an invented problem rather than an actual problem.

> class A(collections.abc.Set, int): pass

Would anyone ever do this and be surprised the sets and ints don't combine perfectly?

If you must, add a footnote to the collections.abc entry for __ne__ noting that __ne__ is inherited.  Or you can restore the definition of Set.__ne__ that was present in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41416>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:56:23 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 14:56:23 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595948183.05.0.0262384660479.issue41328@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e31b8a5cd13ca529e59c1e05d4524ae750a5b5a0 by Miss Islington (bot) in branch '3.9':
bpo-41328: Replace mention of Hudson CI with Travis CI and AppVeyor (GH-21653)
https://github.com/python/cpython/commit/e31b8a5cd13ca529e59c1e05d4524ae750a5b5a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:57:15 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 14:57:15 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595948235.04.0.0121481394647.issue41328@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 59cfba326801a1fd809836c16887f53765f9680f by Miss Islington (bot) in branch '3.8':
bpo-41328: Replace mention of Hudson CI with Travis CI and AppVeyor (GH-21653)
https://github.com/python/cpython/commit/59cfba326801a1fd809836c16887f53765f9680f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:00:45 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Jul 2020 15:00:45 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595948445.76.0.0720612693808.issue41355@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree that the current implementation is wonky.  

The implementation should use linkat(2) whenever it is available, that's the only portable way to honour the follow_symlinks flag as POSIX says that the behaviour for link(2) with symbolic links is implementation defined.

>From a quick experiment link(2) on Linux behaves like linkat(2) without AT_SYMLINK_FOLLOW.  On macOS link(2) behaves like linkat(2) *with* AT_SYMLINK_FOLLOW.   

That means os.link behaviour is currently different on macOS and Linux. 

I think it would be worthwhile to try to standardise the behaviour. Given the relative market sizes it I'd go for the current behaviour on Linux (with explicit tests!), even if that might not be backward compatible on macOS.

I'd also add a configure test for the behaviour of link(2) and error out when the user specifies a value for follow_symlinks that's not compatible with link(2) when linkat(2) is not available.  Or maybe only do this when the user explicitly passes in a value for this argument (make it a tri-state).

Also: note that the current macOS installers on macOS don't look at the follow_symlinks flag at all, they are build on macOS 10.9 where linkat(2) is not available (unlink macOS 10.10 or later).  That's why I noticed this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:06:34 2020
From: report at bugs.python.org (Dmytro Litvinov)
Date: Tue, 28 Jul 2020 15:06:34 +0000
Subject: [issue41328] In unittest doc,
 replace Hudson CI with Travis and Appveyor
In-Reply-To: <1595017716.52.0.971991236143.issue41328@roundup.psfhosted.org>
Message-ID: <1595948794.53.0.202401254522.issue41328@roundup.psfhosted.org>


Dmytro Litvinov <litvinov.dmytro.it at gmail.com> added the comment:

Done: https://bugs.python.org/issue41420

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41328>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:06:02 2020
From: report at bugs.python.org (Dmytro Litvinov)
Date: Tue, 28 Jul 2020 15:06:02 +0000
Subject: [issue41420] Academic Free License v. 2.1 link is not found and is
 obsolete
Message-ID: <1595948762.34.0.747967566864.issue41420@roundup.psfhosted.org>


New submission from Dmytro Litvinov <litvinov.dmytro.it at gmail.com>:

Link to Acamedic Free License v. 2.1(https://www.samurajdata.se/opensource/mirror/licenses/afl-2.1.php) at https://www.python.org/psf/contrib/ is not found. Also, Guido mentioned that version 2.1 seems obsolete and we may need to review that with the lawyer (https://bugs.python.org/issue41328#msg374495).

----------
assignee: docs at python
components: Documentation
messages: 374501
nosy: DmytroLitvinov, docs at python
priority: normal
severity: normal
status: open
title: Academic Free License v. 2.1 link is not found and is obsolete
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41420>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:22:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 15:22:55 +0000
Subject: [issue41420] Academic Free License v. 2.1 link is not found and is
 obsolete
In-Reply-To: <1595948762.34.0.747967566864.issue41420@roundup.psfhosted.org>
Message-ID: <1595949775.23.0.72351749395.issue41420@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41420>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:35:58 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 15:35:58 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595950558.77.0.747960004745.issue40948@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +20808
pull_request: https://github.com/python/cpython/pull/21661

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:35:58 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 15:35:58 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595950558.65.0.868829064999.issue41412@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +20807
pull_request: https://github.com/python/cpython/pull/21661

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:36:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 15:36:07 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595950567.61.0.229148664352.issue41412@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 37a06cbe5c17c2aa6ad938339fd42531a8a0bea0 by Steve Dower in branch 'master':
bpo-41412 and bpo-40948: Windows installer updates (GH-21656)
https://github.com/python/cpython/commit/37a06cbe5c17c2aa6ad938339fd42531a8a0bea0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:36:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 15:36:07 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595950567.51.0.1232974103.issue40948@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 37a06cbe5c17c2aa6ad938339fd42531a8a0bea0 by Steve Dower in branch 'master':
bpo-41412 and bpo-40948: Windows installer updates (GH-21656)
https://github.com/python/cpython/commit/37a06cbe5c17c2aa6ad938339fd42531a8a0bea0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:55:46 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 15:55:46 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595951746.03.0.14276884611.issue41412@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 95cc37f6b8e895a5042e2a10e5d9026429e06342 by Miss Islington (bot) in branch '3.9':
bpo-41412 and bpo-40948: Windows installer updates (GH-21656)
https://github.com/python/cpython/commit/95cc37f6b8e895a5042e2a10e5d9026429e06342


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:59:27 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 15:59:27 +0000
Subject: [issue41420] Academic Free License v. 2.1 link is not found and is
 obsolete
In-Reply-To: <1595949775.27.0.0267083480905.issue41420@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+LZhJaG_+gDLLQgU7doLS7ogo-4Bk2EEjG1oTtia-JoA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I've sent an email to our lawyer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41420>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:55:45 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jul 2020 15:55:45 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595951745.92.0.226601857282.issue40948@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 95cc37f6b8e895a5042e2a10e5d9026429e06342 by Miss Islington (bot) in branch '3.9':
bpo-41412 and bpo-40948: Windows installer updates (GH-21656)
https://github.com/python/cpython/commit/95cc37f6b8e895a5042e2a10e5d9026429e06342


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 12:01:51 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 16:01:51 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595937871.34.0.962385424752.issue41411@roundup.psfhosted.org>
Message-ID: <CAP7+vJL5f6vXJs80FdJkDi078h8D77E8vf35ASq1cUmuP6d0xA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Note that there already is something in the tutorial about f-strings (in
inputoutput.rst, labeled tut-f-strings), and the intro has a link to their
reference manual description in the "see also" section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Tue Jul 28 12:35:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 28 Jul 2020 16:35:08 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1595954108.7.0.337873239211.issue40841@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> I think that both functions for detecting file type, by name and by content

I think so too, mime sniffing would not be a way to alternate the method based on the file extension. Both APIs should be provided.

> should not we add also the code for detecting the text encoding based on other algorithms used in browsers

I already add the code for text encoding detection based on the whatwg standard so if this API is landed, yes text encoding detection will be supported.(e.g utf-16be)
IMHO, there would be use-cases since today python is used a lot for text data handling (for example crawling, data pre-processing) 

There would be the question that the standard for the browser is appropriate for the python stdlib module.
My answer is that the whatwg standard could be the one of best standards to follow if make the decision to provide mime sniffing.

The standard handle mime types that are widely used in the real world not only for browser but also HTTP server or else.

One of the big stress to maintain mime-types detection is that considering how many mime-types should be supported.
Luckily, whatwg can be the strong standard to make the decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Tue Jul 28 12:53:46 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 16:53:46 +0000
Subject: [issue41412] After installation on Windows7,
 64bit Python 3.9.0b5 reports "api-ms-win-core-path-l1-1-0.dll"
 missing and doesn't start
In-Reply-To: <1595869655.44.0.79039964549.issue41412@roundup.psfhosted.org>
Message-ID: <1595955226.43.0.96965308561.issue41412@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Leaving this open until we can validate on the next release. I don't have convenient access to old versions of Windows anymore (and don't have time to deal with inconvenient access this week).

----------
priority: release blocker -> deferred blocker
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41412>
_______________________________________

From report at bugs.python.org  Tue Jul 28 12:54:02 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jul 2020 16:54:02 +0000
Subject: [issue40948] Better identify Windows installer as installer only,
 not runner
In-Reply-To: <1591877055.43.0.578200145114.issue40948@roundup.psfhosted.org>
Message-ID: <1595955242.45.0.881351515341.issue40948@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40948>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:04:18 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 17:04:18 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1595954108.7.0.337873239211.issue40841@roundup.psfhosted.org>
Message-ID: <CAP7+vJJ0dNm9z2e+99fSCLCwox4Bb=egTh8iZGsnPVPDB=hGLw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

When the standard says "trust the filename" it is talking to the
application, not to the sniffing library. The library should provide the
tool for applications to follow the standard, but I don't see a reason why
we would have to enforce how applications call the library. Since we agree
there are use cases beyond what the standard has thought of for combining
sniffing the data and guessing based on the filename, we should make that
possible, the standard's exhortations notwithstanding.

Python is not a browser; a browser could be an application written in
Python. Python therefulre should provide tools that are useful to implement
a browser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:44:22 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Tue, 28 Jul 2020 17:44:22 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595958262.94.0.479535267219.issue41380@roundup.psfhosted.org>


Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com> added the comment:

Moved to https://bugs.python.org/issue41418

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:45:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Jul 2020 17:45:22 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595958322.72.0.571722828485.issue41355@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> So, do you think it should just be documented that follow_symlinks is effectively ignored with os.link() on most platforms that claim to support it, unless either src_dir_fd or dst_dir_fd is used?

At this stage, I am just trying to understand all the possibilities in the design space and I don't have a preferred path. I just wanted to point out that we should take into account that many things may be broken if we make changes that are backwards-incompatible in a low-level function and we must have that in mind

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:46:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Jul 2020 17:46:11 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1595958371.6.0.370632447917.issue41355@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:48:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Jul 2020 17:48:46 +0000
Subject: [issue41409] deque.pop(index) is not supported
In-Reply-To: <1595859535.68.0.0423357008273.issue41409@roundup.psfhosted.org>
Message-ID: <1595958526.58.0.483541163155.issue41409@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am convinced by Raymond's argument, it seems that with the current state of the ABC classes and semantics the most pragmatical solution is the status quo. It would be a weird if deque is a Sequence but not a MutableSequence because it can clearly be mutated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41409>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:50:37 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jul 2020 17:50:37 +0000
Subject: [issue36661] Missing dataclass decorator import in dataclasses module
 docs
In-Reply-To: <1555616208.44.0.536731608649.issue36661@roundup.psfhosted.org>
Message-ID: <1595958637.8.0.100538650164.issue36661@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks for noticing, Karl!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36661>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:50:24 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jul 2020 17:50:24 +0000
Subject: [issue36661] Missing dataclass decorator import in dataclasses module
 docs
In-Reply-To: <1555616208.44.0.536731608649.issue36661@roundup.psfhosted.org>
Message-ID: <1595958624.76.0.165388912219.issue36661@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36661>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:59:09 2020
From: report at bugs.python.org (David MacIver)
Date: Tue, 28 Jul 2020 17:59:09 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
Message-ID: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>


New submission from David MacIver <david.maciver at gmail.com>:

The following code raises a ZeroDivisionError:


from random import Random

Random(14064741636871487939).paretovariate(0.01)


This raises:

random.py, line 692, in paretovariate
    return 1.0 / u ** (1.0/alpha)
ZeroDivisionError: float division by zero


That specific stack trace is from 3.8.5 but I've tried this on 3.6 and 3.7 as well.

It's a little hard to tell what the intended correct range of parameter values is for paretovariate, and this may just be lack of validation for the alpha < 1 case - perhaps that was never intended to be supported?

Based on some very informal inspection, what seems to happen is that the probability of getting a ZeroDivisionError approaches one as you approach zero. They rarely occur at this level of alpha (0.01), but for alpha=0.001 they seem to occur just under half the time, and for alpha=0.0001 they occur more than 90% of the time.

(For the interested, this bug was found by Hypothesis as part of its own testing of our integration with the Random API)

----------
components: Library (Lib)
messages: 374516
nosy: David MacIver
priority: normal
severity: normal
status: open
title: Random.paretovariate sometimes raises ZeroDivisionError for small alpha
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:03:11 2020
From: report at bugs.python.org (David MacIver)
Date: Tue, 28 Jul 2020 18:03:11 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595959391.29.0.813998382007.issue41421@roundup.psfhosted.org>


David MacIver <david.maciver at gmail.com> added the comment:

I guess on actual inspection of the code (which I should have done before, sorry) it's obvious why this happens: u ** (1.0 / alpha) will round to 0.0 for small values of u, and the smaller alpha is the higher the probability of that happening, in that it happens with probability c ** alpha for some c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:26:29 2020
From: report at bugs.python.org (kale-smoothie)
Date: Tue, 28 Jul 2020 18:26:29 +0000
Subject: [issue41422] C Unpickler memory leak via memo
Message-ID: <1595960789.44.0.329453427634.issue41422@roundup.psfhosted.org>


New submission from kale-smoothie <suraj-patel-95 at outlook.com>:

I'm not familiar with the workings of GC/pickle, but it looks like the traverse code in the C Unpickler omits a visit to the memo, potentially causing a memory leak?

----------
components: Library (Lib)
files: leak_pickler.py
messages: 374518
nosy: kale-smoothie
priority: normal
severity: normal
status: open
title: C Unpickler memory leak via memo
type: resource usage
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49345/leak_pickler.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41422>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:34:04 2020
From: report at bugs.python.org (James Thistlewood)
Date: Tue, 28 Jul 2020 18:34:04 +0000
Subject: [issue41423] `multiprocessing.Array` and
 `multiprocessing.managers.SyncManager.Array` APIs are similar but not the
 same
Message-ID: <1595961244.31.0.535074566554.issue41423@roundup.psfhosted.org>


New submission from James Thistlewood <jamesthistlewood at gmail.com>:

I stumbled across this by trying to implement a call to the latter, while reading the docs for the former.

I think this is quite confusing and unnecessary that the APIs between these two definitions should differ.  The same goes for `multiprocessing.Value` and `multiprocessing.managers.SyncManager.Value`.

This is especially exacerbated by the fact that the docs _are incorrect_. On this page [1], under 'Server process', a link to 'Array' is made. If it were correct, it would link to `multiprocessing.managers.SyncManager.Array`, since it's talking about a manager object - the kind returned by `Manager()`. But it links to `multiprocessing.Array`. Of course, the simple solution would be to change the link to link to the correct place, but I think this shows an unnecessary inconsistency in the API itself.

I don't have a PR for this yet, nor have I fully investigated, but should it be feasible I would like to implement it myself. I'm interested to hear what people think.

[1] https://docs.python.org/3/library/multiprocessing.html#sharing-state-between-processes

----------
components: Library (Lib)
messages: 374519
nosy: jthistle
priority: normal
severity: normal
status: open
title: `multiprocessing.Array` and `multiprocessing.managers.SyncManager.Array` APIs are similar but not the same
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41423>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:35:27 2020
From: report at bugs.python.org (Ben)
Date: Tue, 28 Jul 2020 18:35:27 +0000
Subject: [issue41423] `multiprocessing.Array` and
 `multiprocessing.managers.SyncManager.Array` APIs are similar but not the
 same
In-Reply-To: <1595961244.31.0.535074566554.issue41423@roundup.psfhosted.org>
Message-ID: <1595961327.17.0.859132856497.issue41423@roundup.psfhosted.org>


Change by Ben <benjsimner at gmail.com>:


----------
nosy: +bjs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41423>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:36:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Jul 2020 18:36:30 +0000
Subject: [issue41423] `multiprocessing.Array` and
 `multiprocessing.managers.SyncManager.Array` APIs are similar but not the
 same
In-Reply-To: <1595961244.31.0.535074566554.issue41423@roundup.psfhosted.org>
Message-ID: <1595961390.67.0.811743517099.issue41423@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41423>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:37:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Jul 2020 18:37:42 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595961462.51.0.111151525169.issue41421@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:49:37 2020
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Jul 2020 18:49:37 +0000
Subject: [issue41422] C Unpickler memory leak via memo
In-Reply-To: <1595960789.44.0.329453427634.issue41422@roundup.psfhosted.org>
Message-ID: <1595962177.13.0.511299418676.issue41422@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20809
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21664

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41422>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:00:07 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jul 2020 19:00:07 +0000
Subject: [issue41424] [tkinter] Grammatical error in "Packer" docs
Message-ID: <1595962807.42.0.795060125481.issue41424@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

"Geometry managers are used to specify the relative positioning of the positioning of widgets within their container".

Remove "of the positioning".

----------
assignee: docs at python
components: Documentation
keywords: newcomer friendly
messages: 374520
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: [tkinter] Grammatical error in "Packer" docs
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41424>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:07:30 2020
From: report at bugs.python.org (kale-smoothie)
Date: Tue, 28 Jul 2020 19:07:30 +0000
Subject: [issue41422] C Unpickler memory leak via memo
In-Reply-To: <1595960789.44.0.329453427634.issue41422@roundup.psfhosted.org>
Message-ID: <1595963250.89.0.142353741324.issue41422@roundup.psfhosted.org>


kale-smoothie <suraj-patel-95 at outlook.com> added the comment:

The leak demonstrated in the attachment is, to my understanding, caused by memoizing the closure returned from the `find_class` method that's used to intercept global references. The cycle is then: Unpickler, memo table, closure, Unpickler (via cell reference to `self`).

My proposed patch visits every entry in the memo table.

Pre-patch run of valgrind on leak_pickler.py:

==20339== HEAP SUMMARY:
==20339==     in use at exit: 190,189,238 bytes in 2,406,919 blocks
==20339==   total heap usage: 3,150,288 allocs, 743,369 frees, 233,766,596 bytes allocated
==20339== 
==20339== LEAK SUMMARY:
==20339==    definitely lost: 0 bytes in 0 blocks
==20339==    indirectly lost: 0 bytes in 0 blocks
==20339==      possibly lost: 190,176,150 bytes in 2,406,835 blocks
==20339==    still reachable: 13,088 bytes in 84 blocks
==20339==         suppressed: 0 bytes in 0 blocks
==20339== Rerun with --leak-check=full to see details of leaked memory

Post-patch run of valgrind on leak_pickler.py:

==20880== HEAP SUMMARY:
==20880==     in use at exit: 667,277 bytes in 6,725 blocks
==20880==   total heap usage: 2,853,739 allocs, 2,847,014 frees, 216,473,216 bytes allocated
==20880== 
==20880== LEAK SUMMARY:
==20880==    definitely lost: 0 bytes in 0 blocks
==20880==    indirectly lost: 0 bytes in 0 blocks
==20880==      possibly lost: 654,624 bytes in 6,646 blocks
==20880==    still reachable: 12,653 bytes in 79 blocks
==20880==         suppressed: 0 bytes in 0 blocks
==20880== Rerun with --leak-check=full to see details of leaked memory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41422>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:08:10 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jul 2020 19:08:10 +0000
Subject: [issue41425] [tkinter] "Coupling Widget Variables" example missing
 code
Message-ID: <1595963290.36.0.00195793356515.issue41425@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

The example for https://docs.python.org/3.8/library/tkinter.html#coupling-widget-variables is missing:

1. Imports
2. Code to launch the example

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 374522
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: [tkinter] "Coupling Widget Variables" example missing code
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41425>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:19:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 19:19:11 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595963951.38.0.248208896001.issue41421@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:23:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jul 2020 19:23:14 +0000
Subject: [issue41422] C Unpickler memory leak via memo
In-Reply-To: <1595960789.44.0.329453427634.issue41422@roundup.psfhosted.org>
Message-ID: <1595964194.69.0.053181928018.issue41422@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41422>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:37:06 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Jul 2020 19:37:06 +0000
Subject: [issue41303] perf_counter result does not count system sleep time in
 Mac OS
In-Reply-To: <1594816999.52.0.200760723432.issue41303@roundup.psfhosted.org>
Message-ID: <1595965026.38.0.536908140865.issue41303@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

macOS 10.12 also has clock_gettime(), which would allow using the generic code path (although the current path must be kept for older versions of macOS).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41303>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:46:20 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jul 2020 19:46:20 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
Message-ID: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

https://docs.python.org/3/library/curses.html#curses.getmouse

"this method should be call to retrieve"

"call" -> "called"

----------
assignee: docs at python
components: Documentation
keywords: newcomer friendly
messages: 374524
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: [curses] Grammar mistake in curses.getmouse() docs
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Tue Jul 28 16:12:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 20:12:12 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595967132.42.0.783528741816.issue41380@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>From the closed PR: "I'll delete it from turtledemo and it will be at tools/demo file!"

No! turtledemo was in tools/demo in 2.x, where hardly anyone saw it.  It was made into an importable module in 3.0.  A link was later added to the IDLE help menu.  I oppose adding any turtle demos back to tools/demo.  I would rather pull the few tkinter demos into a tkinter.demo subdirectory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Tue Jul 28 16:47:00 2020
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Tue, 28 Jul 2020 20:47:00 +0000
Subject: [issue41427] howto/descriptor.rst unnecessarily mentions
 method.__class__
Message-ID: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>


New submission from Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:

In Doc/howto/descriptor.rst:

    # Internally, the bound method stores the underlying function,
    # the bound instance, and the class of the bound instance.
    >>> d.f.__func__
    <function D.f at 0x1012e5ae8>
    >>> d.f.__self__
    <__main__.D object at 0x1012e1f98>
    >>> d.f.__class__
    <class 'method'>

The bound method (PyMethodObject) does not store "the class of the bound instance" - it only stores the "function" and "self".
d.f.__class__ is the class of the "method" type itself, not the class of d.f's instance (D from d = D())

I think this mention should be removed from the documentation?

----------
assignee: docs at python
components: Documentation
messages: 374526
nosy: Yonatan Goldschmidt, docs at python
priority: normal
severity: normal
status: open
title: howto/descriptor.rst unnecessarily mentions method.__class__
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 16:56:00 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jul 2020 20:56:00 +0000
Subject: [issue36982] Add support for extended color functions in ncurses 6.1
In-Reply-To: <1558406631.2.0.0939623901621.issue36982@roundup.psfhosted.org>
Message-ID: <1595969760.72.0.640670710544.issue36982@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

PR 17536 was based on the original PR 13534 and has now gone through a couple of rounds of code review. Other than a missing doc change, everything in PR 13534 is covered (and updated) in PR 17536 so I've closed the original PR.  Other than adding the doc change and a final core developer review of the last requested changes, this *should* be good to go.

We really need to get this merged since, without it, Python builds fail with the newer versions of ncurses now in most distributions.  Once it is merged into master for 3.10, ?ukasz can provide direction about whether and when it should be backported to 3.9 and/or 3.8.

----------
nosy: +hpj, lukasz.langa, ned.deily, serhiy.storchaka
priority: normal -> critical
stage: patch review -> commit review
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36982>
_______________________________________

From report at bugs.python.org  Tue Jul 28 16:56:02 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Jul 2020 20:56:02 +0000
Subject: [issue41410] Opening a file in binary mode makes a difference on all
 platforms in Python 3
In-Reply-To: <1595863285.0.0.72970010693.issue41410@roundup.psfhosted.org>
Message-ID: <1595969762.75.0.68419600391.issue41410@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think deleting the last sentence is sufficient.

----------
keywords: +newcomer friendly
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41410>
_______________________________________

From report at bugs.python.org  Tue Jul 28 16:58:02 2020
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Tue, 28 Jul 2020 20:58:02 +0000
Subject: [issue41427] howto/descriptor.rst unnecessarily mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595969882.34.0.51753376786.issue41427@roundup.psfhosted.org>


Change by Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:


----------
keywords: +patch
pull_requests: +20810
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21665

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 17:11:34 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jul 2020 21:11:34 +0000
Subject: [issue36630] failure of test_colors_funcs in test_curses with ncurses
 6.1
In-Reply-To: <1555270378.07.0.766030130411.issue36630@roundup.psfhosted.org>
Message-ID: <1595970694.79.0.903994599944.issue36630@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I believe this is now just a duplicate of Issue36982. If there is anything not already covered there, let's discuss it there.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add support for extended color functions in ncurses 6.1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36630>
_______________________________________

From report at bugs.python.org  Tue Jul 28 17:15:27 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jul 2020 21:15:27 +0000
Subject: [issue41405] python 3.9.0b5 test
In-Reply-To: <1595797866.02.0.778171485398.issue41405@roundup.psfhosted.org>
Message-ID: <1595970927.98.0.235993626739.issue41405@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

As xtreak noted earlier, the test_tk failure is documented in Issue41306.  It is a result of changes in Tk 8.6.x itself but the tests need to be fixed to work with older and newer versions of Tk 8.6.x. And the curses issues were originally reported in Issue36630 which has been superseded by Issue36982. If there is further discussion needed on either of these two issues, let's use them, please.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_tk test_widgets.ScaleTest fails with Tk 8.6.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41405>
_______________________________________

From report at bugs.python.org  Tue Jul 28 17:18:45 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jul 2020 21:18:45 +0000
Subject: [issue41306] test_tk test_widgets.ScaleTest fails with Tk 8.6.10
In-Reply-To: <1594840353.83.0.567403527611.issue41306@roundup.psfhosted.org>
Message-ID: <1595971125.21.0.00617291348286.issue41306@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

This issue should be fixed for upcoming releases. Nosying ?ukasz for consideration of "release blocker" status.

----------
nosy: +lukasz.langa
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41306>
_______________________________________

From report at bugs.python.org  Tue Jul 28 17:38:45 2020
From: report at bugs.python.org (Irv Kalb)
Date: Tue, 28 Jul 2020 21:38:45 +0000
Subject: [issue41413] IDLE: exit at input() prompt is not complete
In-Reply-To: <1595904269.59.0.561706167779.issue41413@roundup.psfhosted.org>
Message-ID: <513BE523-4758-47F3-A474-66C05E4EB7A6@furrypants.com>


Irv Kalb <Irv at furrypants.com> added the comment:

I have tried the test that Terry outlined (from double clicking on the IDLE icon), and I can confirm that I get the exact same results.  In the menu bar, I see just the Apple icon and "IDLE".  The items in the IDLE menu work (About IDLE and Preferences).  At that point, I have to force quit.

I found the pyshell.py file and the line that you suggested changing.  I can make the change but when I go to save, I get a permissions error and cannot save the file.

Irv

> On Jul 27, 2020, at 7:44 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> 
> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Simpler test.
> 
> Open IDLE Shell (only) from icon or (preferably) terminal.
>>>> input()
>   # Close IDLE without giving input with Window (X), File => exit, or Control/Command-Q.
> Click OK in "Your program is still running" box (from PyShell)
> 
> On Windows, IDLE closes apparently cleanly, but Task Manager shows that (at least usually) the IDLE process moves from Apps to Background processes, with label 'Python x.y.z Shell', where it remains as an inaccessible 20 mb zombie until [End Task]ed.  This is not normal.
> 
> On macOS Mohave, the Shell window and IDLE part of the top menubar disappear, but the Apple part remains with the apple and program name entry ("IDLE" or "Python" depending on whether started from icon or Terminal).  I presume this is the equivalent of Python becoming a background process, except that Apple keeps a visible link to it.  If I start IDLE in Terminal with trailing &, there are initially two processes, and the first remains along with the Apple menu.
> 
> Under the IDLE/Python menu item, About and Preferences still bring up the corresponding dialogs, which worked as far as I tested.  This confirms that the IDLE process is still alive. A couple of times, Quit (Command-Q) worked to quit/crash python, and Segmentation Fault appeared in Terminal once.  Later, Quit did not work and I had to use (apple)=> Force Quit.
> 
> The trivial solution is to not close with input pending.  First, either hit Enter to let the user code run or end-of-file (default ^D) to kill it.  A corresponding patch could enforce this with a message to enter or kill before closing.
> 
> However, I believe the issue is that PyShell.readline uses a nested tk mainloop() as a control mechanism.  Four callbacks, including eof_callback, call quit() to exit the nested mainloop and finish readline.  But the callback has to finish and be pulled off the stack first.  Three of the callbacks return immediately after 'quit()'.  However, PyShell.close continues closing before readline continues.
> 
> When I replaced pyshell line  1016
>        return EditorWindow.close(self)
> with
>        root.after(1, EditorWindow.close self)
> the bug disappears.  The opens a time gap between PyShell.close and EditorWindow.close that allows readline to return '', signalling end-of-file.
> 
> This change also works on my Mac, except that I have to say 'yes' twice to close.
> Irv, please try this replacement on your system.
> 
> ----------
> title: At prompt for input(), pressing Command q kills IDLE -> IDLE: exit at input() prompt is not complete
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue41413>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________

From report at bugs.python.org  Tue Jul 28 17:55:59 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 21:55:59 +0000
Subject: [issue41418] GH-21658: Add snake game to tools/demo!
In-Reply-To: <1595945314.49.0.985793426755.issue41418@roundup.psfhosted.org>
Message-ID: <1595973359.22.0.667271111139.issue41418@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is a duplicate of the original issue, #41380, except that it proposes to put the new file where it does not belong and will be useless, instead of in turtledemo.

----------
assignee:  -> terry.reedy
nosy: +terry.reedy
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed
superseder:  -> Add snake example to turtledemo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41418>
_______________________________________

From report at bugs.python.org  Tue Jul 28 17:58:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 21:58:13 +0000
Subject: [issue41380] Add snake example to turtledemo
In-Reply-To: <1595574811.16.0.254153483734.issue41380@roundup.psfhosted.org>
Message-ID: <1595973493.29.0.44272415127.issue41380@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41380>
_______________________________________

From report at bugs.python.org  Tue Jul 28 18:18:58 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 22:18:58 +0000
Subject: [issue41413] IDLE: exit at input() prompt is not complete
In-Reply-To: <1595872986.33.0.489785676605.issue41413@roundup.psfhosted.org>
Message-ID: <1595974738.0.0.0269033349459.issue41413@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IRv, please, please, snip the message you respond to when replying by email instead of with a browser.

I am guessing that you or someone installed python as root/admin and you are working as non-root. 

I will try to figure out why the change results in the 'running' box appearing twice instead of just once, and if a fix is possible that does not make this happen.  But I have noticed on other close issues that close is at least sometimes called more than once.  The shutdown system has multiple patches and is delicate to change, and not unittested, which would be non-trivial.  The peculiarily of this issue is that it is the initial idle process left running rather than the secondary user code execution process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________

From report at bugs.python.org  Tue Jul 28 18:32:30 2020
From: report at bugs.python.org (Maggie Moss)
Date: Tue, 28 Jul 2020 22:32:30 +0000
Subject: [issue41428] PEP 604 -- Allow writing union types as X | Y
Message-ID: <1595975550.94.0.895278514403.issue41428@roundup.psfhosted.org>


New submission from Maggie Moss <maggiebmoss at gmail.com>:

https://www.python.org/dev/peps/pep-0604/

----------
messages: 374535
nosy: maggiemoss
priority: normal
pull_requests: 20811
severity: normal
status: open
title: PEP 604 -- Allow writing union types as X | Y
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41428>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:24:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 23:24:26 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595978666.18.0.097441660493.issue41421@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:35:28 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 23:35:28 +0000
Subject: [issue35379] IDLE's close fails io is set to None on Mac
In-Reply-To: <1543775410.03.0.788709270274.issue35379@psf.upfronthosting.co.za>
Message-ID: <1595979328.36.0.681163354171.issue35379@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#41413 exposed another double save on Mac issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35379>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:35:48 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 28 Jul 2020 23:35:48 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595979348.64.0.3530282796.issue41421@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm inclined to ignore this. No actual user has complained about this, and I doubt any ever will:  it's got to be rare as hen's teeth to use a parameter outside of, say, [0.1, 10.0], in real life. The division error can't happen for those. For "small" alpha, the distribution simply does contain values too large to represent as binary doubles. So the only other defensible thing to do be done in this case is to return math.inf (or raise OverflowError) - but why slow it down for something no actual user cares about?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:36:08 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 23:36:08 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595979368.03.0.531324690647.issue41421@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The point of the "u = 1.0 - self.random()" line was to prevent the case where *u* was exactly equal to zero; however, as you noted, raising a very small number to a small can round down to zero.

We could wrap the calculation in a try/except to catch the ZeroDivisionError but that is probably insufficient.  The codomain can easily spew beyond the range of a C double:

   >>> alpha = 0.01
   >>> u = 0.005
   >>> 1.0 / u ** (1.0 / alpha)
   1.2676506002282268e+230             <== Huge!

We could clamp the values as is done in gammavariate().  Or we can raise a clean Overflow or Underflow exception but that would be unpleasant for users if it were to arise unexpectedly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:36:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jul 2020 23:36:31 +0000
Subject: [issue41413] IDLE: exit at input() prompt is not complete
In-Reply-To: <1595872986.33.0.489785676605.issue41413@roundup.psfhosted.org>
Message-ID: <1595979390.99.0.290783126581.issue41413@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

More specifically, why the change results the same box twice on Mac but not on Windows.  The previous double-save issue, worst on Mac, was #35379.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:36:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 23:36:31 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595979391.34.0.783055868238.issue41421@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
type:  -> behavior
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:39:56 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 23:39:56 +0000
Subject: [issue41427] howto/descriptor.rst unnecessarily mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595979596.7.0.430410866744.issue41427@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:41:58 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 28 Jul 2020 23:41:58 +0000
Subject: [issue41429] Let fnmatch.filter accept a tuple of patterns
Message-ID: <1595979718.87.0.129861821474.issue41429@roundup.psfhosted.org>


New submission from Andr?s Delfino <adelfino at gmail.com>:

I propose to let fnmatch.filter accept a tuple of patterns as its pat parameter, while still supporting a single string argument (just like str.endswith does).

The code to do this manually and efficiently pretty much involves copying filter.

----------
components: Library (Lib)
messages: 374540
nosy: adelfino
priority: normal
severity: normal
status: open
title: Let fnmatch.filter accept a tuple of patterns
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41429>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:42:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 23:42:49 +0000
Subject: [issue41427] howto/descriptor.rst unnecessarily mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595979769.58.0.40488864551.issue41427@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Good catch.  Thanks for the report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:44:04 2020
From: report at bugs.python.org (James Corbett)
Date: Tue, 28 Jul 2020 23:44:04 +0000
Subject: [issue41046] unittest: make skipTest a classmethod
In-Reply-To: <1592613393.95.0.180040510992.issue41046@roundup.psfhosted.org>
Message-ID: <1595979844.54.0.0642416476914.issue41046@roundup.psfhosted.org>


James Corbett <james.h.corbett at gmail.com> added the comment:

I was careless in my example, it would need to be `cls.skipTest(reason)`. However, that really doesn't have anything to do with why it should be a `classmethod` instead of an instance method: it's so that you can call `skipTest` from `classmethods`, namely `setUpClass` which is called by the `unittest` framework. You can currently call `skipTest` from `setUpClass` only with something ugly like `cls.skipTest(None, reason)` (i.e. passing `None` for the `self` parameter, which works because `self` isn't used).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41046>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:45:25 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 28 Jul 2020 23:45:25 +0000
Subject: [issue41429] Let fnmatch.filter accept a tuple of patterns
In-Reply-To: <1595979718.87.0.129861821474.issue41429@roundup.psfhosted.org>
Message-ID: <1595979925.06.0.759804825842.issue41429@roundup.psfhosted.org>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
keywords: +patch
pull_requests: +20812
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21666

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41429>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:49:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 23:49:13 +0000
Subject: [issue41420] Academic Free License v. 2.1 link is not found and is
 obsolete
In-Reply-To: <1595948762.34.0.747967566864.issue41420@roundup.psfhosted.org>
Message-ID: <1595980153.12.0.350182621744.issue41420@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

A few options present themselves:

- We could switch to AFL 3.0 (https://opensource.org/licenses/AFL-3.0). This will require some review by our lawyer.

- We could link to another copy of AFL 2.1. Honestly the original one seems pretty odd.

- We could link to the archive.org copy of AFL 2.1.

But looking at archive.org I find this copy:

https://web.archive.org/web/20170827133353/https://www.samurajdata.se/opensource/mirror/licenses/afl-2.1.php

which has the following text, in red, at the top:

Larry Rosen has ceased to use or recommend any version of the Academic Free License below version 2.1

(Note that Larry Rosen is the AFL's author.)

So maybe the first option, get a legal opinion on switching to AFL 3.0, is our best recourse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41420>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:48:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jul 2020 23:48:37 +0000
Subject: [issue41427] howto/descriptor.rst unnecessarily mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595980117.74.0.535541218904.issue41427@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The origin of the error was an incorrect update from Python 2 semantics where the class was exposed as an attribute:

Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 16:24:34) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license()" for more information.
>>> class A:
	def f(self, x):
		return x
	
>>> a = A()
>>> bm = a.f
>>> bm.im_class
<class __main__.A at 0x1002daf30>
>>> bm.im_self
<__main__.A instance at 0x103a204b0>
>>> bm.im_func
<function f at 0x1004ed950>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:53:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jul 2020 23:53:09 +0000
Subject: [issue41420] Academic Free License v. 2.1 link is not found and is
 obsolete
In-Reply-To: <1595948762.34.0.747967566864.issue41420@roundup.psfhosted.org>
Message-ID: <1595980389.69.0.045103504534.issue41420@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I also found what looks like a copy of AFL 2.1 on Python's own wiki:

https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq/AFL-2.1

(Of course, being a wiki, this has the disadvantage of being publicly editable. :-)

Yet another option presents itself: do away with the AFL 2.1 and just require Apache 2.0. See https://en.wikipedia.org/wiki/License_proliferation for more on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41420>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:54:41 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 28 Jul 2020 23:54:41 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595980481.61.0.414985389667.issue41421@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

BTW, if we have to "do something", how about changing

return 1.0 / u ** (1.0/alpha)

to the mathematically equivalent

return (1.0 / u) ** (1.0/alpha)

? Not sure about Linux-y boxes, but on Windows that would raise OverflowError instead of ZeroDivisionError. Which makes more sense, because the Pareto variable we're _trying_ to produce is too large to represent.  If it returns math.inf on some box instead, same thing.

Or, also faster, and suffering fewer rounding errors,

return  u ** (-1.0 / alpha)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:00:19 2020
From: report at bugs.python.org (James Corbett)
Date: Wed, 29 Jul 2020 00:00:19 +0000
Subject: [issue41430] Document C docstring behavior
Message-ID: <1595980819.55.0.541837599725.issue41430@roundup.psfhosted.org>


New submission from James Corbett <james.h.corbett at gmail.com>:

As described in https://stackoverflow.com/questions/25847035/what-are-signature-and-text-signature-used-for-in-python-3-4, https://bugs.python.org/issue20586, and https://stackoverflow.com/questions/50537407/add-a-signature-with-annotations-to-extension-methods,  it is possible to embed a signature in docstrings for C functions, so that `help` and `inspect.signature` work properly on them. However, this functionality isn't documented anywhere. I think something should be added to the "extending and embedding the Python interpreter" tutorial.

----------
assignee: docs at python
components: Documentation
messages: 374547
nosy: docs at python, jameshcorbett
priority: normal
severity: normal
status: open
title: Document C docstring behavior
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41430>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:05:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2020 00:05:17 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1595981117.57.0.0187635324933.issue41421@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't feel a need to change anything, my post hit a few seconds after yours :-) 

That said, "return u ** (-1.0 / alpha)" would be a slight, but nice improvement.

It might also be reasonable to document a safe range of alpha values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:11:04 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2020 00:11:04 +0000
Subject: [issue41427] howto/descriptor.rst incorrectly mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595981464.66.0.356685944314.issue41427@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: howto/descriptor.rst unnecessarily mentions method.__class__ -> howto/descriptor.rst incorrectly mentions method.__class__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:16:28 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2020 00:16:28 +0000
Subject: [issue41416] Restore default implementation of __ne__ in mixins Set
 and Mapping
In-Reply-To: <1595918093.33.0.049225231479.issue41416@roundup.psfhosted.org>
Message-ID: <1595981788.14.0.803476503681.issue41416@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg374497

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41416>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:18:36 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2020 00:18:36 +0000
Subject: [issue41416] Restore default implementation of __ne__ in mixins Set
 and Mapping
In-Reply-To: <1595918093.33.0.049225231479.issue41416@roundup.psfhosted.org>
Message-ID: <1595981916.23.0.461146314012.issue41416@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If you want to add back the __ne__() method, that would be fine.

FWIW, "class A(collections.abc.Set, int)" seems pretty exotic to me.  I wouldn't have expected that work out well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41416>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:29:38 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jul 2020 00:29:38 +0000
Subject: [issue41431] Optimize dict_merge for copy
Message-ID: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

Although there are dict.copy() and PyDict_Copy(), dict_merge can be used for copying dict.

* d={}; d.update(orig)
* d=dict(orig)
* d=orig.copy() # orig has many dummy keys.

----------
components: Interpreter Core
messages: 374550
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Optimize dict_merge for copy
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:41:12 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jul 2020 00:41:12 +0000
Subject: [issue41431] Optimize dict_merge for copy
In-Reply-To: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>
Message-ID: <1595983272.75.0.540804494739.issue41431@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +20813
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21669

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:50:51 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jul 2020 00:50:51 +0000
Subject: [issue41431] Optimize dict_merge for copy
In-Reply-To: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>
Message-ID: <1595983851.73.0.0947059112265.issue41431@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Microbenchmark for commit cf4f61ce50e07f7ccd3aef991647050c8da058f9.

# timeit -s 'd=dict.fromkeys(range(8))' -- 'dict(d)'
Mean +- std dev: [master] 311 ns +- 2 ns -> [patched] 144 ns +- 1 ns: 2.16x faster (-54%)

# timeit -s 'd=dict.fromkeys(range(1000))' -- 'dict(d)'
Mean +- std dev: [master] 21.6 us +- 0.2 us -> [patched] 7.67 us +- 0.09 us: 2.81x faster (-64%)

# timeit -s 'd=dict.fromkeys(range(8))' -- '{}.update(d)'
Mean +- std dev: [master] 301 ns +- 5 ns -> [patched] 149 ns +- 1 ns: 2.01x faster (-50%)

# timeit -s 'd=dict.fromkeys(range(1000))' -- '{}.update(d)'
Mean +- std dev: [master] 21.4 us +- 0.2 us -> [patched] 7.64 us +- 0.07 us: 2.80x faster (-64%)

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:57:19 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 29 Jul 2020 00:57:19 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595984239.08.0.202692118747.issue38156@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a74eea238f5baba15797e2e8b570d153bc8690a7 by Benjamin Peterson in branch 'master':
closes bpo-38156: Always handle interrupts in PyOS_StdioReadline. (GH-21569)
https://github.com/python/cpython/commit/a74eea238f5baba15797e2e8b570d153bc8690a7


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:57:28 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 00:57:28 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595984248.77.0.48375764595.issue38156@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20814
pull_request: https://github.com/python/cpython/pull/21670

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:57:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 00:57:36 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595984256.38.0.76476139349.issue38156@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20815
pull_request: https://github.com/python/cpython/pull/21671

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:16:26 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 01:16:26 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595985386.87.0.1319356559.issue38156@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 22216107f2890e7ee2ab055e4983b76ff9c62169 by Miss Islington (bot) in branch '3.9':
closes bpo-38156: Always handle interrupts in PyOS_StdioReadline. (GH-21569)
https://github.com/python/cpython/commit/22216107f2890e7ee2ab055e4983b76ff9c62169


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:16:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 01:16:27 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595985386.87.0.1319356559.issue38156@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 22216107f2890e7ee2ab055e4983b76ff9c62169 by Miss Islington (bot) in branch '3.9':
closes bpo-38156: Always handle interrupts in PyOS_StdioReadline. (GH-21569)
https://github.com/python/cpython/commit/22216107f2890e7ee2ab055e4983b76ff9c62169


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:16:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 01:16:27 +0000
Subject: [issue38156] input fucntion raises SystemError after specific input.
In-Reply-To: <1568370698.83.0.595206707223.issue38156@roundup.psfhosted.org>
Message-ID: <1595985387.01.0.241551624735.issue38156@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7cfede6859586f77f786bda56af4698ae2245f56 by Miss Islington (bot) in branch '3.8':
closes bpo-38156: Always handle interrupts in PyOS_StdioReadline. (GH-21569)
https://github.com/python/cpython/commit/7cfede6859586f77f786bda56af4698ae2245f56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38156>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:25:49 2020
From: report at bugs.python.org (James Corbett)
Date: Wed, 29 Jul 2020 01:25:49 +0000
Subject: [issue41430] Document C docstring behavior
In-Reply-To: <1595980819.55.0.541837599725.issue41430@roundup.psfhosted.org>
Message-ID: <1595985949.75.0.0289929526948.issue41430@roundup.psfhosted.org>


Change by James Corbett <james.h.corbett at gmail.com>:


----------
keywords: +patch
pull_requests: +20816
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21673

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41430>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:38:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 01:38:36 +0000
Subject: [issue41427] howto/descriptor.rst incorrectly mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595986716.4.0.204833868331.issue41427@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20817
pull_request: https://github.com/python/cpython/pull/21667

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:38:46 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 01:38:46 +0000
Subject: [issue41427] howto/descriptor.rst incorrectly mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595986726.28.0.946704194816.issue41427@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20818
pull_request: https://github.com/python/cpython/pull/21668

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 22:05:35 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jul 2020 02:05:35 +0000
Subject: [issue41431] Optimize dict_merge for copy
In-Reply-To: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>
Message-ID: <1595988335.29.0.124634508156.issue41431@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

To reduce code size, I am considering to remove clone_combined_dict. I will check how PyDict_Copy() is performance critical.

This is microbenchmark result of d.copy() and dict(d).

$ ./python -m pyperf timeit --compare-to ./python-master -s 'd=dict.fromkeys(range(1000))' -- 'd.copy()'
python-master: ..................... 4.36 us +- 0.07 us
python: ..................... 5.96 us +- 0.10 us

Mean +- std dev: [python-master] 4.36 us +- 0.07 us -> [python] 5.96 us +- 0.10 us: 1.37x slower (+37%)

$ ./python -m pyperf timeit --compare-to ./python-master -s 'd=dict.fromkeys(range(1000))' -- 'dict(d)'
python-master: ..................... 21.6 us +- 0.2 us
python: ..................... 6.01 us +- 0.09 us

Mean +- std dev: [python-master] 21.6 us +- 0.2 us -> [python] 6.01 us +- 0.09 us: 3.59x faster (-72%)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:09:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jul 2020 03:09:39 +0000
Subject: [issue41428] PEP 604 -- Allow writing union types as X | Y
In-Reply-To: <1595975550.94.0.895278514403.issue41428@roundup.psfhosted.org>
Message-ID: <1595992179.09.0.910578159597.issue41428@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41428>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:10:35 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jul 2020 03:10:35 +0000
Subject: [issue41431] Optimize dict_merge for copy
In-Reply-To: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>
Message-ID: <1595992235.95.0.104121730588.issue41431@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

PyDict_Copy() is not used in eval loop or calling functions. So removing clone_combined_dict() is a considerable option.

Another option is to use clone_combined_dict() in dict_merge, instead of adding dict_copy2().

Pros: No performance regression. PyDict_Copy() is as fast as before.
Cons: Can not "fast copy" split dict and dirty dict.

I suppose most dict used by `dict(d)` or `dict.update(d)` is clean and combined. So I will implement the second option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:18:29 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jul 2020 03:18:29 +0000
Subject: [issue41431] Optimize dict_merge for copy
In-Reply-To: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>
Message-ID: <1595992709.29.0.756134185097.issue41431@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +20819
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:19:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2020 03:19:27 +0000
Subject: [issue41427] howto/descriptor.rst incorrectly mentions
 method.__class__
In-Reply-To: <1595969220.64.0.879377287441.issue41427@roundup.psfhosted.org>
Message-ID: <1595992767.21.0.20648790614.issue41427@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41427>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:33:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Jul 2020 03:33:23 +0000
Subject: [issue41432] IDLE: Handle bad highlight tab color config
Message-ID: <1595993603.42.0.358377843337.issue41432@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

https://stackoverflow.com/questions/35397377/python-freezes-when-configuring-idle froze IDLE with a custom theme missing 'colours for the blinker and highlighting'.  I reported some experiments there.  Tracebacks might help, but

Proposal 1: check theme before try to paint.  All keys present?  Replace missing with normal colors.


https://stackoverflow.com/questions/63137659/idle-crashing-when-i-press-configure-idle froze IDLE with a custom theme with a bad color "#00224".

 File "C:\Users\...\idlelib\configdialog.py", line 1279, in paint_theme_sample
    self.highlight_sample.tag_config(element, **colors)
...
_tkinter.TclError: invalid color name "#00224"

Proposal 2: wrap line in try-except, if error text matches, extract bad color, replace any occurrence of bad color with "#000000" (black) or "#FFFFFF" (white), report to user with suggestion to edit.  Maybe save first.  Should do within loop in case more errors.

----------
assignee: terry.reedy
components: IDLE
messages: 374558
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Handle bad highlight tab color config
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41432>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:50:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Jul 2020 04:50:10 +0000
Subject: [issue41431] Optimize dict_merge for copy
In-Reply-To: <1595982578.69.0.880267074289.issue41431@roundup.psfhosted.org>
Message-ID: <1595998210.55.0.836252099131.issue41431@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41431>
_______________________________________

From report at bugs.python.org  Wed Jul 29 01:39:59 2020
From: report at bugs.python.org (Peixing Xin)
Date: Wed, 29 Jul 2020 05:39:59 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1596001199.91.0.825043719548.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +20820
pull_request: https://github.com/python/cpython/pull/21675

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Jul 29 01:57:24 2020
From: report at bugs.python.org (Tatsunosuke Shimada)
Date: Wed, 29 Jul 2020 05:57:24 +0000
Subject: [issue41433] Logging libraries BufferingHandler flushed twice at
 shutdown
Message-ID: <1596002244.65.0.208232248615.issue41433@roundup.psfhosted.org>


New submission from Tatsunosuke Shimada <adam.is.t521 at gmail.com>:

BufferingHandler

I expected function flush of BufferingHandler called once but it is called twice. 
This is due to that shutdown calls flush before close function which calls flush function inside.
(Faced this issue on my custom implementation of flush function.)

Seems that there is no need of calling flush inside BufferingHandler.

Following is the link to the code of function shutdown and Buffering Handler
https://github.com/python/cpython/blob/0124f2b5e0f88ee7f5d40fca96dbf087cbe4764b/Lib/logging/handlers.py#L1286
https://github.com/python/cpython/blob/a74eea238f5baba15797e2e8b570d153bc8690a7/Lib/logging/__init__.py#L2151

This issue could be also related.
https://bugs.python.org/issue26559

----------
components: Library (Lib)
messages: 374559
nosy: adamist521, vinay.sajip
priority: normal
severity: normal
status: open
title: Logging libraries BufferingHandler flushed twice at shutdown
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41433>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:07:05 2020
From: report at bugs.python.org (Tatsunosuke Shimada)
Date: Wed, 29 Jul 2020 06:07:05 +0000
Subject: [issue41433] Logging libraries BufferingHandler flushed twice at
 shutdown
In-Reply-To: <1596002244.65.0.208232248615.issue41433@roundup.psfhosted.org>
Message-ID: <1596002825.97.0.864691998489.issue41433@roundup.psfhosted.org>


Tatsunosuke Shimada <adam.is.t521 at gmail.com> added the comment:

Found related issue.
https://bugs.python.org/issue901330

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41433>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:14:09 2020
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 29 Jul 2020 06:14:09 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1596003249.58.0.401581621717.issue41282@roundup.psfhosted.org>


Change by Hugo van Kemenade <hugovk+python at gmail.com>:


----------
nosy: +hugovk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:54:57 2020
From: report at bugs.python.org (wyz23x2)
Date: Wed, 29 Jul 2020 06:54:57 +0000
Subject: [issue41434] IDLE: Warn user on "Run Module" if file is not .py/.pyw
Message-ID: <1596005697.8.0.893586453742.issue41434@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

It would be great if IDLE shows a note when a non-Python file is attempted to run.

----------
assignee: terry.reedy
components: IDLE
messages: 374561
nosy: terry.reedy, wyz23x2
priority: normal
severity: normal
status: open
title: IDLE: Warn user on "Run Module" if file is not .py/.pyw
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41434>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:57:08 2020
From: report at bugs.python.org (wyz23x2)
Date: Wed, 29 Jul 2020 06:57:08 +0000
Subject: [issue41434] IDLE: Warn user on "Run Module" if file is not .py/.pyw
In-Reply-To: <1596005697.8.0.893586453742.issue41434@roundup.psfhosted.org>
Message-ID: <1596005828.91.0.563397870922.issue41434@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

It should be able to turn on/off this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41434>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:57:22 2020
From: report at bugs.python.org (wyz23x2)
Date: Wed, 29 Jul 2020 06:57:22 +0000
Subject: [issue41434] IDLE: Option to warn user on "Run Module" if file is not
 .py/.pyw
In-Reply-To: <1596005697.8.0.893586453742.issue41434@roundup.psfhosted.org>
Message-ID: <1596005842.43.0.0949515807439.issue41434@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
title: IDLE: Warn user on "Run Module" if file is not .py/.pyw -> IDLE: Option to warn user on "Run Module" if file is not .py/.pyw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41434>
_______________________________________

From report at bugs.python.org  Wed Jul 29 03:59:00 2020
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Wed, 29 Jul 2020 07:59:00 +0000
Subject: [issue41418] GH-21658: Add snake game to tools/demo!
In-Reply-To: <1595945314.49.0.985793426755.issue41418@roundup.psfhosted.org>
Message-ID: <1596009540.16.0.396642428086.issue41418@roundup.psfhosted.org>


Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com> added the comment:

I knew, but its not support for turtledemo cause, canvas is so small for this example! Mr @terry.reedy!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41418>
_______________________________________

From report at bugs.python.org  Wed Jul 29 04:34:00 2020
From: report at bugs.python.org (David MacIver)
Date: Wed, 29 Jul 2020 08:34:00 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1596011640.02.0.813515904448.issue41421@roundup.psfhosted.org>


David MacIver <david.maciver at gmail.com> added the comment:

I should say, I don't actually care about this bug at all: I only ran into it because of trying to recreate the random API and testing that my recreation worked sensibly. I thought I'd do the good citizen thing and report it, but I'm totally fine with any resolution and given that that code has been unchanged for at least 18 years I doubt anyone else has ever run into this problem.

I do think it would be beneficial to document the range of reasonable alpha on paretovariate - the lack of such documentation is the only reason I hit this at all - but I think leaving the behaviour as is would be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Wed Jul 29 05:01:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Jul 2020 09:01:57 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1596013317.84.0.0234255784977.issue41421@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

+1 for "u ** (-1.0 / alpha)"!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Wed Jul 29 05:13:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jul 2020 09:13:42 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596014022.47.0.931693298128.issue40360@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

After this patch test_lib2to3 generates a PendingDeprecationWarning. It can be silenced as it's intentional to avoid test failures while running tests with -Werror.

./python.exe -Wall -m test test_lib2to3
0:00:00 load avg: 2.31 Run tests sequentially
0:00:00 load avg: 2.31 [1/1] test_lib2to3
/Users/kasingar/stuff/python/cpython/Lib/test/test_lib2to3.py:1: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  from lib2to3.tests import load_tests

== Tests result: SUCCESS ==

1 test OK.

Total duration: 9.0 sec
Tests result: SUCCESS

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul 29 05:21:29 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 29 Jul 2020 09:21:29 +0000
Subject: [issue40075] _tkinter PythonCmd fails to acquire GIL
In-Reply-To: <1585224969.87.0.649895216825.issue40075@roundup.psfhosted.org>
Message-ID: <1596014489.57.0.125862311352.issue40075@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Sorry for taking so long to do something with this issue. Can you please explain *why* (mostly because I don't really have a clue) acquiring the GIL fixes this crash (I am not disputing that it does - I have compared the current 3.9 branch against yours and confirmed this). Also, can it be reproduced with just the stdlib (so we can write a unittest for this)? Is it an assumption in QT about the GIL rather than a problem with _tkinter?

----------
nosy: +epaine
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40075>
_______________________________________

From report at bugs.python.org  Wed Jul 29 05:31:45 2020
From: report at bugs.python.org (Alexey)
Date: Wed, 29 Jul 2020 09:31:45 +0000
Subject: [issue24964] Add tunnel CONNECT response headers to httplib /
 http.client
In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za>
Message-ID: <1596015104.99.0.135479076071.issue24964@roundup.psfhosted.org>


Change by Alexey <Namyotkin at mail.ru>:


----------
nosy: +Namyotkin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24964>
_______________________________________

From report at bugs.python.org  Wed Jul 29 06:59:13 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 29 Jul 2020 10:59:13 +0000
Subject: [issue41434] IDLE: Option to warn user on "Run Module" if file is not
 Python source
In-Reply-To: <1596005697.8.0.893586453742.issue41434@roundup.psfhosted.org>
Message-ID: <1596020353.33.0.816322202024.issue41434@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I think this sounds like a very good idea. I would recommend using the `ispythonsource` method (in the editor class) as it already has all the logic you need while also checking for a start line like "#!/usr/bin/env python" (rather than relying solely on the extension).

----------
nosy: +epaine
title: IDLE: Option to warn user on "Run Module" if file is not .py/.pyw -> IDLE: Option to warn user on "Run Module" if file is not Python source

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41434>
_______________________________________

From report at bugs.python.org  Wed Jul 29 08:28:25 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 29 Jul 2020 12:28:25 +0000
Subject: [issue40072] Win7/Python3.8/asyncio IPv6 UDP Server raise OSError
 when recved any packet
In-Reply-To: <1585186958.06.0.811123062641.issue40072@roundup.psfhosted.org>
Message-ID: <1596025705.07.0.760844119732.issue40072@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I just got hit by this bug too. Attached is the repro script I came up with before finding this report.

----------
nosy: +alex.gronholm
Added file: https://bugs.python.org/file49346/udptest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40072>
_______________________________________

From report at bugs.python.org  Wed Jul 29 08:29:48 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 29 Jul 2020 12:29:48 +0000
Subject: [issue40072] Win7/Python3.8/asyncio IPv6 UDP Server raise OSError
 when recved any packet
In-Reply-To: <1585186958.06.0.811123062641.issue40072@roundup.psfhosted.org>
Message-ID: <1596025788.31.0.985249151862.issue40072@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

My repro script also demonstrates that when binding to an interface, the bug is not triggered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40072>
_______________________________________

From report at bugs.python.org  Wed Jul 29 08:50:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Jul 2020 12:50:05 +0000
Subject: [issue41134] distutils.dir_util.copy_tree FileExistsError when
 updating symlinks
In-Reply-To: <1593228362.42.0.387933635808.issue41134@roundup.psfhosted.org>
Message-ID: <1596027005.24.0.384808716418.issue41134@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
dependencies: +Add race-free os.link and os.symlink wrapper / helper
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41134>
_______________________________________

From report at bugs.python.org  Wed Jul 29 09:31:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Jul 2020 13:31:12 +0000
Subject: [issue41434] IDLE: Option to warn user on "Run Module" if file is not
 Python source
In-Reply-To: <1596005697.8.0.893586453742.issue41434@roundup.psfhosted.org>
Message-ID: <1596029472.93.0.831154482315.issue41434@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I disagree.  IDLE already shows a note -- in the editor window -- with the first noted divergence from python code marked.  We are trying to keep IDLE relatively simple and not clutter it with trivial options.

ispythonsource is just a guess.  The decision is whether turn on the colorizer and do python indents.  For a new file, assume that it will be python code.  Returning True for a directory is an error that is never hit as directories are not opened.  Python files do not have to have a .py extensions, and files that have a .py extension do not have to be python files.  But IDLE encourages use of the convention.

I would consider adding a note to the SyntaxError box when the error is on the first line.  Something like "Is this really a Python code file?"

  The only actual running of non-Python files I have seen reported, and I believe at least twice, is very beginner beginners running the saved Shell log, which begins "Python 3.x...", with the 3 highlighted.  If this were recognized, the message might be "If this is a log of an interactive session, you cannot run it."

But I am not sure if this would really solve the problem of extreme ignorance.  And anything added would have to have a test, and would be a possible maintenance burden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41434>
_______________________________________

From report at bugs.python.org  Wed Jul 29 09:46:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Jul 2020 13:46:13 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596030373.71.0.962212802924.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Which patch are you referring to? Is it already merged?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul 29 10:23:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jul 2020 14:23:14 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596032594.7.0.0660887361274.issue40360@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I was referring to PR https://github.com/python/cpython/pull/19663 (commit-503de7149d03bdcc671dcbbb5b64f761bb192b4d) that was merged as part of this issue. It started emitting PendingDeprecationWarning but was not silenced in the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul 29 10:41:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Jul 2020 14:41:40 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596033700.56.0.424093481542.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Okay, so if you know what to do please do it. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Jul 29 10:46:07 2020
From: report at bugs.python.org (Alexey Namyotkin)
Date: Wed, 29 Jul 2020 14:46:07 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1596033967.94.0.164583374388.issue7291@roundup.psfhosted.org>


Change by Alexey Namyotkin <Namyotkin at mail.ru>:


----------
nosy: +alexey.namyotkin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Wed Jul 29 11:36:59 2020
From: report at bugs.python.org (Jessica Ridgley)
Date: Wed, 29 Jul 2020 15:36:59 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1596037019.46.0.859705097877.issue7291@roundup.psfhosted.org>


Change by Jessica Ridgley <code3jessica at gmail.com>:


----------
nosy: +Jessica Ridgley
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Wed Jul 29 11:39:46 2020
From: report at bugs.python.org (Julien Danjou)
Date: Wed, 29 Jul 2020 15:39:46 +0000
Subject: [issue41435] Allow to retrieve ongoing exception handled by every
 threads
Message-ID: <1596037186.46.0.97878619969.issue41435@roundup.psfhosted.org>


New submission from Julien Danjou <julien at danjou.info>:

In order to do statistical profiling on raised exception, having the ability to poll all the running threads for their currently handled exception would be fantastic.

There is an exposed function named `sys._current_frames()` that allows to list the current frame handled by CPython. Having an equivalent for `sys._current_exceptions()` that would return the content of `sys.exc_info()` for each running thread would solve the issue.

----------
components: Interpreter Core
messages: 374575
nosy: jd
priority: normal
severity: normal
status: open
title: Allow to retrieve ongoing exception handled by every threads
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41435>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:30:45 2020
From: report at bugs.python.org (Samran)
Date: Wed, 29 Jul 2020 16:30:45 +0000
Subject: [issue41436] BUG a simple "and" and "or"
Message-ID: <1596040245.85.0.344075232599.issue41436@roundup.psfhosted.org>


New submission from Samran <iamsamran1d at gmail.com>:

#this is the code

from random import randint

num = randint(1,10)

print(type(num))

print(num)

ch = None                                                                                           #tried changing this tried converting types

guess = 0

print(type(guess))

print("Welcome to guessing game: ")

 

 

while ch != 'n' or ch != 'N':                                            #here is the bug this statement is not running. It works with ?and?

                while( guess != num):

                                guess = int(input("Enter your guess?  "))

                                if guess == num:

                                                print("You Guessed Congratz")

               

 

                ch=input("Enter 'y' to play or 'n' to exit: ")

               

 

                if ch=='y' or ch == 'Y':

                                guess= 0

                                num = randint(1,10)

 

print("Thankyou for playing.")

----------
components: Tests
files: Command Prompt - python  test.py 29-Jul-20 9_16_22 PM (2).png
messages: 374576
nosy: Samran
priority: normal
severity: normal
status: open
title: BUG a simple "and" and "or"
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49347/Command Prompt - python  test.py 29-Jul-20 9_16_22 PM (2).png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:57:43 2020
From: report at bugs.python.org (James Corbett)
Date: Wed, 29 Jul 2020 16:57:43 +0000
Subject: [issue41436] BUG a simple "and" and "or"
In-Reply-To: <1596040245.85.0.344075232599.issue41436@roundup.psfhosted.org>
Message-ID: <1596041862.7.0.841562583323.issue41436@roundup.psfhosted.org>


James Corbett <james.h.corbett at gmail.com> added the comment:

I think this would have been a better fit for a StackOverflow issue: https://stackoverflow.com/questions/tagged/python. Also, it's not a compilation error and it doesn't have anything to do with CPython's testing framework. 

Anyway, I don't think this is a bug. For a string `ch`, it is always true that either `ch != 'n'` or `ch != 'N'`---no string is equal to both `'N'` and `'n'`. Therefore your `while` condition will always be true and the loop will always continue.

As you already noted, your loop will terminate properly if you used `and`. You could also rewrite it as `while ch not in ('n', 'N'):` which I think is clearer.

----------
nosy: +jameshcorbett, xtreak
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:57:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jul 2020 16:57:43 +0000
Subject: [issue41436] BUG a simple "and" and "or"
In-Reply-To: <1596040245.85.0.344075232599.issue41436@roundup.psfhosted.org>
Message-ID: <1596041863.43.0.546293452546.issue41436@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Below is the formatted program for easier reading. In the while clause you ask for the user to enter n to exit but you check (ch != n or ch != N) so on entering "n" the first condition is false but second clause is true. For "N" it's vice-versa. You want to continue the game as long as ch is not 'n' or "N'. Hence using not(ch == 'n' or ch == 'N') will help in exiting the program. This website is for bugs related to CPython itself. Please refer to stack overflow or other mailing lists in future.

Thanks.

from random import randint

num = randint(1, 10)

print(type(num))
print(num)

ch = None  # tried changing this tried converting types
guess = 0
print(type(guess))
print("Welcome to guessing game: ")


while (
    ch != "n" or ch != "N"
):  # here is the bug this statement is not running. It works with ?and?
    while guess != num:
        guess = int(input("Enter your guess?  "))
        if guess == num:
            print("You Guessed Congratz")
            ch = input("Enter 'y' to play or 'n' to exit: ")
            if ch == "y" or ch == "Y":
                guess = 0
                num = randint(1, 10)

print("Thankyou for playing.")


Fixed program : 

from random import randint

num = randint(1, 10)

print(type(num))
print(num)

ch = None  # tried changing this tried converting types
guess = 0
print(type(guess))
print("Welcome to guessing game: ")


while not (
    ch == "n" or ch == "N"
):  # Play until the ch is not n or N 
    while guess != num:
        guess = int(input("Enter your guess?  "))
        if guess == num:
            print("You Guessed Congratz")
            ch = input("Enter 'y' to play or 'n' to exit: ")
            if ch == "y" or ch == "Y":
                guess = 0
                num = randint(1, 10)

print("Thankyou for playing.")

----------
nosy: +jameshcorbett, xtreak
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:57:42 2020
From: report at bugs.python.org (James Corbett)
Date: Wed, 29 Jul 2020 16:57:42 +0000
Subject: [issue41436] BUG a simple "and" and "or"
In-Reply-To: <1596040245.85.0.344075232599.issue41436@roundup.psfhosted.org>
Message-ID: <1596041862.7.0.841562583323.issue41436@roundup.psfhosted.org>


James Corbett <james.h.corbett at gmail.com> added the comment:

I think this would have been a better fit for a StackOverflow issue: https://stackoverflow.com/questions/tagged/python. Also, it's not a compilation error and it doesn't have anything to do with CPython's testing framework. 

Anyway, I don't think this is a bug. For a string `ch`, it is always true that either `ch != 'n'` or `ch != 'N'`---no string is equal to both `'N'` and `'n'`. Therefore your `while` condition will always be true and the loop will always continue.

As you already noted, your loop will terminate properly if you used `and`. You could also rewrite it as `while ch not in ('n', 'N'):` which I think is clearer.

----------
nosy: +jameshcorbett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:58:12 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jul 2020 16:58:12 +0000
Subject: [issue41436] BUG a simple "and" and "or"
In-Reply-To: <1596040245.85.0.344075232599.issue41436@roundup.psfhosted.org>
Message-ID: <1596041892.0.0.0572498250723.issue41436@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Wed Jul 29 13:19:10 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jul 2020 17:19:10 +0000
Subject: [issue41395] pickle and pickletools cli interface doesn't close input
 and output file.
In-Reply-To: <1595686330.63.0.838691465271.issue41395@roundup.psfhosted.org>
Message-ID: <1596043150.17.0.506602101195.issue41395@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +20821
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21676

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41395>
_______________________________________

From report at bugs.python.org  Wed Jul 29 13:53:31 2020
From: report at bugs.python.org (Why Me)
Date: Wed, 29 Jul 2020 17:53:31 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1596045211.19.0.0218283564979.issue40395@roundup.psfhosted.org>


Why Me <animewasafatalmistake at gmail.com> added the comment:

I had the same issue (win 10, py 3.8.5, executable installer). The solution i've found is to install python to non-standard catalog (D:/ instead of windows user folder which is under access protection). In this case, the file "easy_install.exe" will be created in the Scripts folder. Then open console inside the folder and call "easy_install pip", this will install pip. After that just copy everything to the standard catalog and don't forget to change the environment variables. Hope this helps.

----------
components:  -Installation
nosy: +Why Me

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:13:12 2020
From: report at bugs.python.org (Zhiming Wang)
Date: Wed, 29 Jul 2020 18:13:12 +0000
Subject: [issue41437] SIGINT blocked by socket operations like recv on Windows
Message-ID: <1596046392.19.0.70440136745.issue41437@roundup.psfhosted.org>


New submission from Zhiming Wang <zmwangx at gmail.com>:

I noticed that on Windows, socket operations like recv appear to always block SIGINT until it's done, so if a recv hangs, Ctrl+C cannot interrupt the program. (I'm a *nix developer investigating a behavioral problem of my program on Windows, so please excuse my limited knowledge of Windows.)

Consider the following example where I spawn a TCP server that stalls connections by 5 seconds in a separate thread, and use a client to connect to it on the main thread. I then try to interrupt the client with Ctrl+C.

    import socket
    import socketserver
    import time
    import threading


    interrupted = threading.Event()


    class HoneypotServer(socketserver.TCPServer):
        # Stall each connection for 5 seconds.
        def get_request(self):
            start = time.time()
            while time.time() - start < 5 and not interrupted.is_set():
                time.sleep(0.1)
            return self.socket.accept()


    class EchoHandler(socketserver.BaseRequestHandler):
        def handle(self):
            data = self.request.recv(1024)
            self.request.sendall(data)


    class HoneypotServerThread(threading.Thread):
        def __init__(self):
            super().__init__()
            self.server = HoneypotServer(("127.0.0.1", 0), EchoHandler)

        def run(self):
            self.server.serve_forever(poll_interval=0.1)


    def main():
        start = time.time()
        server_thread = HoneypotServerThread()
        server_thread.start()
        sock = socket.create_connection(server_thread.server.server_address)
        try:
            sock.sendall(b"hello")
            sock.recv(1024)
        except KeyboardInterrupt:
            print(f"processed SIGINT {time.time() - start:.3f}s into the program")
            interrupted.set()
        finally:
            sock.close()
            server_thread.server.shutdown()
            server_thread.join()


    if __name__ == "__main__":
        main()

On *nix systems the KeyboardInterrupt is processed immediately. On Windows, the KeyboardInterrupt is always processed more than 5 seconds into the program, when the recv is finished.

I suppose this is a fundamental limitation of Windows? Is there any workaround (other than going asyncio)?

Btw, I learned about SIGBREAK, which when unhandled seems to kill the process immediately, but that means no chance of cleanup. I tried to handle SIGBREAK but whenever a signal handler is installed, the behavior reverts to that of SIGINT -- the handler is called only after 5 seconds have passed.

(I'm attaching a socket_sigint_sigbreak.py which is a slightly expanded version of my sample program above, showing my attempt at handler SIGBREAK. Both

    python .\socket_sigint_sigbreak.py --sigbreak-handler interrupt

and

    python .\socket_sigint_sigbreak.py --sigbreak-handler exit

stall for 5 seconds.)

----------
components: Windows
files: socket_sigint_sigbreak.py
messages: 374580
nosy: paul.moore, steve.dower, tim.golden, zach.ware, zmwangx
priority: normal
severity: normal
status: open
title: SIGINT blocked by socket operations like recv on Windows
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49348/socket_sigint_sigbreak.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41437>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:22:59 2020
From: report at bugs.python.org (Sebastien Williams-Wynn)
Date: Wed, 29 Jul 2020 18:22:59 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596046979.46.0.74643690494.issue41426@roundup.psfhosted.org>


Change by Sebastien Williams-Wynn <s.williamswynn.mail at gmail.com>:


----------
keywords: +patch
nosy: +Sebastien Williams-Wynn
nosy_count: 2.0 -> 3.0
pull_requests: +20822
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21677

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:22:56 2020
From: report at bugs.python.org (James Corbett)
Date: Wed, 29 Jul 2020 18:22:56 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
 using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1596046976.69.0.509196250414.issue9625@roundup.psfhosted.org>


James Corbett <james.h.corbett at gmail.com> added the comment:

I would love to get this issue resolved; it seems like everyone agrees that it's a bug. It came up for me recently: https://bugs.python.org/issue41047. Judging from the comments above, the consensus is that the relevant line, `self._check_value(action, value)` should either be replaced with something like `if isinstance(value, collections.abc.Sequence): for v in value: self._check_value(action, v)` or be removed entirely.

I think the line should just be removed. I think it's fair to assume that users of `argparse` know what they're doing, so I think they should be allowed to pass default values that conflict with `choices`. Also, removing the line makes the behavior consistent with the optionals, which don't check whether default values are in `choices`. See the below script:

```
import argparse


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--foo", nargs="+", default=[-1], choices=range(10))
    parser.add_argument("--bar", nargs="*", default=-1, choices=range(10))
    parser.add_argument("pos", nargs="?", default=-1, choices=range(10))
    args = parser.parse_args()
    print(args)


if __name__ == '__main__':
    main()
```

Which yields:
```
$ python argparse_test.py 
Namespace(foo=[-1], bar=-1, pos=-1)
```

----------
nosy: +jameshcorbett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9625>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:36:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 18:36:53 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596047813.88.0.386535444649.issue41426@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ba18c0b13ba3c08077ea3db6658328523823a33f by Sebastien Williams-Wynn in branch 'master':
bpo-41426 Fix grammar in curses.getmouse() documentation (GH-21677)
https://github.com/python/cpython/commit/ba18c0b13ba3c08077ea3db6658328523823a33f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:37:28 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 18:37:28 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596047848.12.0.830259872743.issue41426@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20824
pull_request: https://github.com/python/cpython/pull/21679

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:37:18 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 18:37:18 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596047838.36.0.531850352171.issue41426@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +20823
pull_request: https://github.com/python/cpython/pull/21678

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:44:01 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 18:44:01 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596048241.51.0.286889152749.issue41426@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 607ba9deffacc57983978a28c74282dfabcb455d by Miss Islington (bot) in branch '3.9':
bpo-41426 Fix grammar in curses.getmouse() documentation (GH-21677)
https://github.com/python/cpython/commit/607ba9deffacc57983978a28c74282dfabcb455d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:44:56 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jul 2020 18:44:56 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596048296.8.0.499552485993.issue41426@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 038827d0f59076f52e9797018ead12b1295cddc2 by Miss Islington (bot) in branch '3.8':
bpo-41426 Fix grammar in curses.getmouse() documentation (GH-21677)
https://github.com/python/cpython/commit/038827d0f59076f52e9797018ead12b1295cddc2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 14:46:06 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jul 2020 18:46:06 +0000
Subject: [issue41426] [curses] Grammar mistake in curses.getmouse() docs
In-Reply-To: <1595965580.82.0.751899511239.issue41426@roundup.psfhosted.org>
Message-ID: <1596048366.14.0.689696915546.issue41426@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41426>
_______________________________________

From report at bugs.python.org  Wed Jul 29 15:39:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Jul 2020 19:39:12 +0000
Subject: [issue37586] macOS: posix_spawn(..., setsid=True)
In-Reply-To: <1563024457.33.0.250849204696.issue37586@roundup.psfhosted.org>
Message-ID: <1596051552.19.0.129731799019.issue37586@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I just started running into a failure that looks like this on some private builds (Xcode_11.3.1 on macOS-10.14.6-x86_64-i386-64bit):

======================================================================
FAIL: test_setsid (test.test_posix.TestPosixSpawnP)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/1/s/Lib/test/test_posix.py", line 1692, in test_setsid
    self.assertNotEqual(parent_sid, child_sid)
AssertionError: 1 == 1

Is that this issue? Or something else?

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37586>
_______________________________________

From report at bugs.python.org  Wed Jul 29 17:14:59 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 29 Jul 2020 21:14:59 +0000
Subject: [issue41355] os.link(..., follow_symlinks=False) without linkat(3)
In-Reply-To: <1595323684.61.0.723587728817.issue41355@roundup.psfhosted.org>
Message-ID: <1596057298.99.0.408564581045.issue41355@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the analysis Eryk!  I think you are right, changing the default to match the behavior that people have actually been experiencing on `os.link(src, dst)` makes sense.

Possible suggestion:

We can go one step further if anyone believes it is likely to be necessary: Preserve the exiting buggy behavior regardless of src_dir_fd= value when follow_symlinks is not explicitly provided as an argument.  This way the behavior for people who did not specify it remains unchanged <= 3.9.  This would be the principal of no surprise.  (it'd effectively become a tri-state _UNSPECIFIED/True/False value where _UNSPECIFIED depends on the mess of conditionals described by Eryk)

Documentation up through 3.9 should be updated to note the oddity.

In 3.8 & 3.9 if it _is_ explicitly specified, fixing the bug so that it actually honors that makes sense.

In 3.10 we should honor the new =False default without this tri-state behavior bug-compatible-by-default at all.

This is more complicated to implement.  I'd also be happy with the already described "just updating the default to False and fixing forward in 3.10 to actually honor True properly."

META: Regarding macOS, can we update the macOS version used to build the installers for 3.10?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41355>
_______________________________________

From report at bugs.python.org  Wed Jul 29 17:25:44 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Jul 2020 21:25:44 +0000
Subject: [issue40075] _tkinter PythonCmd fails to acquire GIL
In-Reply-To: <1585224969.87.0.649895216825.issue40075@roundup.psfhosted.org>
Message-ID: <1596057944.05.0.568480014929.issue40075@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

At a glance, it looks like ENTER_PYTHON will *restore* the GIL on the current thread, but it may be coming in on a thread that's never seen the GIL before.

"The GIL" is actually the Python thread state, which is actually a per-thread data structure that's either active/locked or inactive/unlocked. If the current thread doesn't have a thread state, PyGILState_Ensure will create one, while ENTER_PYTHON will not.

So the underlying issue is probably that the callbacks are coming in from a thread that they shouldn't be, and really ought to be marshalled back into the correct event loop first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40075>
_______________________________________

From report at bugs.python.org  Wed Jul 29 17:31:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Jul 2020 21:31:15 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1596058275.23.0.581928425974.issue40395@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It might help, but it will leave your install broken in a number of other ways.

For other people finding this issue, please share your install logs (look in %TEMP% for the most recently created set of "python*.log" files). Also share your PATH, PYTHONPATH and PYTHONHOME environment variables (if they are set), and any other versions of Python you have installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Wed Jul 29 17:31:23 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Jul 2020 21:31:23 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1596058283.45.0.0508775483945.issue40395@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
components: +Installation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:17:28 2020
From: report at bugs.python.org (Yerken Tussupbekov)
Date: Wed, 29 Jul 2020 22:17:28 +0000
Subject: [issue41438] TimeoutError behavior changes on async.wait_for from
 python3.7
Message-ID: <1596061048.21.0.803910276646.issue41438@roundup.psfhosted.org>


New submission from Yerken Tussupbekov <erkentus0001 at gmail.com>:

```
import asyncio
from concurrent import futures


logging.basicConfig(
    level=logging.DEBUG,
    format="[%(asctime)s %(name)s %(levelname)s]: %(message)s",
    datefmt="%H:%M:%S %d-%m-%y",
)
logger: logging.Logger = logging.getLogger("ideahitme")


async def too_long() -> None:
    await asyncio.sleep(2)


async def run() -> None:
    try:
        await asyncio.wait_for(too_long(), 1)
    except futures.TimeoutError:
        logger.info("concurrent.futures.TimeoutError happened")
    except asyncio.TimeoutError:
        logger.info("asyncio.TimeoutError happened")


if __name__ == "__main__":
    asyncio.run(run())
```

In python 3.8.4 running this script will print:

asyncio.TimeoutError happened

In python 3.7.5 running this script will print:

concurrent.futures.TimeoutError happened

This is a breaking change which I didn't see announced in the changelog. What is the expected behavior here ?

----------
components: asyncio
messages: 374589
nosy: Yerken Tussupbekov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: TimeoutError behavior changes on async.wait_for from python3.7
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41438>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:20:55 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 29 Jul 2020 22:20:55 +0000
Subject: [issue41437] SIGINT blocked by socket operations like recv on Windows
In-Reply-To: <1596046392.19.0.70440136745.issue41437@roundup.psfhosted.org>
Message-ID: <1596061255.87.0.146848383548.issue41437@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Winsock is inherently asynchronous. It implements synchronous functions by using an alertable wait for the completion of an asynchronous I/O request. Python doesn't implement anything for a console Ctrl+C event to alert the main thread when it's blocked in an alterable wait. NTAPI NtAlertThread will alert a thread in this case, but it won't help here because Winsock just rewaits when alerted. 

You need a user-mode asynchronous procedure call (APC) to make the waiting thread cancel all of its pended I/O request packets (IRPs) for the given file (socket) handle. Specifically, open a handle to the thread, and call QueueUserAPC to queue an APC to the thread that calls WinAPI CancelIo on the file handle. (I don't suggest using the newer CancelIoEx function from an arbitrary thread context in this case. It would be simpler than queuing an APC to the target thread, but you don't have an OVERLAPPED record to cancel a specific IRP, so it would cancel IRPs for all threads.)

Here's a context manager that temporarily sets a Ctrl+C handler that implements the above suggestion:

    import ctypes
    import threading
    import contextlib

    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    CTRL_C_EVENT = 0
    THREAD_SET_CONTEXT = 0x0010

    @contextlib.contextmanager
    def ctrl_cancel_async_io(file_handle):
        apc_sync_event = threading.Event()
        hthread = kernel32.OpenThread(THREAD_SET_CONTEXT, False,
            kernel32.GetCurrentThreadId())
        if not hthread:
            raise ctypes.WinError(ctypes.get_last_error())

        @ctypes.WINFUNCTYPE(None, ctypes.c_void_p)
        def apc_cancel_io(ignored):
            kernel32.CancelIo(file_handle)
            apc_sync_event.set()

        @ctypes.WINFUNCTYPE(ctypes.c_uint, ctypes.c_uint)
        def ctrl_handler(ctrl_event):
            # For a Ctrl+C cancel event, queue an async procedure call
            # to the target thread that cancels pending async I/O for
            # the given file handle.
            if ctrl_event == CTRL_C_EVENT:
                kernel32.QueueUserAPC(apc_cancel_io, hthread, None)
                # Synchronize here in case the APC was queued to the
                # main thread, else apc_cancel_io might get interrupted
                # by a KeyboardInterrupt.
                apc_sync_event.wait()
            return False # chain to next handler

        try:
            kernel32.SetConsoleCtrlHandler(ctrl_handler, True)
            yield
        finally:
            kernel32.SetConsoleCtrlHandler(ctrl_handler, False)
            kernel32.CloseHandle(hthread)


Use it as follows in your sample code:

    with ctrl_cancel_async_io(sock.fileno()):
        sock.sendall(b"hello")
        sock.recv(1024)

Note that this requires the value of sock.fileno() to be an NT kernel handle for a file opened in asynchronous mode. This is the case for a socket.

HTH

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41437>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:28:39 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Jul 2020 22:28:39 +0000
Subject: [issue41438] TimeoutError behavior changes on async.wait_for from
 python3.7
In-Reply-To: <1596061048.21.0.803910276646.issue41438@roundup.psfhosted.org>
Message-ID: <1596061719.71.0.631927338819.issue41438@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> In python 3.8.4 running this script will print:

> asyncio.TimeoutError happened

This is the expected behavior in 3.8.

> This is a breaking change which I didn't see announced in the changelog.

Yeah, looks like this wasn't mentioned in what's new or elsewhere in the docs. :(

Do you want to submit a PR to fix that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41438>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:13:21 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 29 Jul 2020 23:13:21 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1596064401.59.0.582410954775.issue40841@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Start and end position of the signature must be accounted for, not all file signature start at ``0`` or ``< 512`` bytes

Rather then writing all the signatures manually might be a good idea to use already collected resource like https://www.garykessler.net/library/file_sigs.html

----------
nosy: +YoSTEALTH

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:13:20 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2020 23:13:20 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
 using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1596064400.36.0.543200480957.issue9625@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Paul, what is your current thinking on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9625>
_______________________________________

From report at bugs.python.org  Wed Jul 29 22:41:18 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Thu, 30 Jul 2020 02:41:18 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1596076878.33.0.469848605038.issue41411@roundup.psfhosted.org>


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


----------
pull_requests: +20825
pull_request: https://github.com/python/cpython/pull/21681

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Wed Jul 29 22:51:59 2020
From: report at bugs.python.org (Samran)
Date: Thu, 30 Jul 2020 02:51:59 +0000
Subject: [issue41436] BUG a simple "and" and "or"
In-Reply-To: <1596041862.7.0.841562583323.issue41436@roundup.psfhosted.org>
Message-ID: <5f2235cc.1c69fb81.935bf.036f@mx.google.com>


Samran <iamsamran1d at gmail.com> added the comment:

Thanks a lot. I am beginner and will try stack overflow next time. Depending on the error type. Thank you again I learned a lot.

Sent from Mail for Windows 10

From: James Corbett
Sent: Wednesday, July 29, 2020 9:57 PM
To: iamsamran1d at gmail.com
Subject: [issue41436] BUG a simple "and" and "or"

James Corbett <james.h.corbett at gmail.com> added the comment:

I think this would have been a better fit for a StackOverflow issue: https://stackoverflow.com/questions/tagged/python. Also, it's not a compilation error and it doesn't have anything to do with CPython's testing framework. 

Anyway, I don't think this is a bug. For a string `ch`, it is always true that either `ch != 'n'` or `ch != 'N'`---no string is equal to both `'N'` and `'n'`. Therefore your `while` condition will always be true and the loop will always continue.

As you already noted, your loop will terminate properly if you used `and`. You could also rewrite it as `while ch not in ('n', 'N'):` which I think is clearer.

----------
nosy: +jameshcorbett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Wed Jul 29 22:55:56 2020
From: report at bugs.python.org (Samran)
Date: Thu, 30 Jul 2020 02:55:56 +0000
Subject: [issue41436] BUG a simple "and" and "or"
In-Reply-To: <1596041863.43.0.546293452546.issue41436@roundup.psfhosted.org>
Message-ID: <5f2236b9.1c69fb81.63816.0c7b@mx.google.com>


Samran <iamsamran1d at gmail.com> added the comment:

Thanks a lot. I am beginner and will try stack overflow next time. Depending on the error type. Thank you again I learned a lot.

Sent from Mail for Windows 10

From: Karthikeyan Singaravelan
Sent: Wednesday, July 29, 2020 9:57 PM
To: iamsamran1d at gmail.com
Subject: [issue41436] BUG a simple "and" and "or"

Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Below is the formatted program for easier reading. In the while clause you ask for the user to enter n to exit but you check (ch != n or ch != N) so on entering "n" the first condition is false but second clause is true. For "N" it's vice-versa. You want to continue the game as long as ch is not 'n' or "N'. Hence using not(ch == 'n' or ch == 'N') will help in exiting the program. This website is for bugs related to CPython itself. Please refer to stack overflow or other mailing lists in future.

Thanks.

from random import randint

num = randint(1, 10)

print(type(num))
print(num)

ch = None  # tried changing this tried converting types
guess = 0
print(type(guess))
print("Welcome to guessing game: ")

while (
    ch != "n" or ch != "N"
):  # here is the bug this statement is not running. It works with ?and?
    while guess != num:
        guess = int(input("Enter your guess?  "))
        if guess == num:
            print("You Guessed Congratz")
            ch = input("Enter 'y' to play or 'n' to exit: ")
            if ch == "y" or ch == "Y":
                guess = 0
                num = randint(1, 10)

print("Thankyou for playing.")

Fixed program : 

from random import randint

num = randint(1, 10)

print(type(num))
print(num)

ch = None  # tried changing this tried converting types
guess = 0
print(type(guess))
print("Welcome to guessing game: ")

while not (
    ch == "n" or ch == "N"
):  # Play until the ch is not n or N 
    while guess != num:
        guess = int(input("Enter your guess?  "))
        if guess == num:
            print("You Guessed Congratz")
            ch = input("Enter 'y' to play or 'n' to exit: ")
            if ch == "y" or ch == "Y":
                guess = 0
                num = randint(1, 10)

print("Thankyou for playing.")

----------
nosy: +jameshcorbett, xtreak
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41436>
_______________________________________

From report at bugs.python.org  Thu Jul 30 00:12:39 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 30 Jul 2020 04:12:39 +0000
Subject: [issue6143] IDLE - clear and restart the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1596082359.61.0.926306177806.issue6143@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 7.0 -> 8.0
pull_requests: +20826
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21682

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Thu Jul 30 00:21:22 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 30 Jul 2020 04:21:22 +0000
Subject: [issue6143] IDLE - clear and restart the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1596082882.87.0.27333957065.issue6143@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created PR 21682 to add a "Clear and Restart" item to the "Shell" menu.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Thu Jul 30 01:12:38 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Thu, 30 Jul 2020 05:12:38 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1596085958.04.0.846079495281.issue41411@roundup.psfhosted.org>


Ama Aje My Fren <amaajemyfren at gmail.com> added the comment:

Hi,

Thanks Ezio for the detailed response.

> In the list of proposed solutions in my first message, 1-3 should be quite easy to implement.  This leaves us with 4-5.

To the best of my seeing there are only two places in the documentation that have information about f-strings. The tutorial[0] and the reference[1]
I have done PR 21681 that adds index to the tutorial although searching[2][3] does not seem to be better now that the reference has an index.

> The lexical analysis is probably fine as is.
I agree.

> The introduction in the tutorial should mention f-strings ....

This is there[0] but it _IS_ hard to find, when you don't know it is there.
It may not be very "introduction-y", and if you like I can make a go at trying to reword it.

> The stdtypes page is already quite long and crowded ...

True. But is this wrong? In my feeling this is reference documentation. It should be accurate, complete and clear. It may not need to be "textbook-like".

Some thoughts:
- There may be benefit in reorganising stdtypes.rst to improve the flow without changing the actual content. This could mean breaking it up into a number of documents rather than the monolith it is.
- It does feel like printf[4] was plugged in later because str.format()[5] had been explained earlier. (Although I believe printf came before str.format()). A first time reader of the document will find it hard to know the one way that is right when it comes to formatting.
- f-strings should probably also be described here because it _is_ built in, no? It may not be accurate to say it is in /Lib/strings. There is no reference that a developer can just look at to remind/confirm to themselves how to "do it".

> So, unless we add a separate page somewhere

This is why I was thinking of a HOWTO. Going back to your original pain in msg371912, someone wanted the f-string documentation and:
-- It was hard to find. (indexing? better table of contents?)
-- It was not very helpful WHEN it was found. (A second entry with f-strings in Lib that is easier for a dev to use?)

But now (and this is mainly to me) it appears that another problem is a need to consistently, clearly, and in one place describe the various elements/nuances/eccentricities of presenting data in Python: 
  - string
  - string.Formatter,
  - string.Template,
  - str.format()
  - f-string
  - Format Specification Mini-Language
  - maybe even __format__ and conversion?
  - etc

I propose one of the following two:
1) A new section in Library documentation just to handle strings, then systematically removing them elsewhere.(Built-In Functions, Built-In Types, Text Processing Services)
2) We take all that Python history and explain it in a HOWTO, and add a developer friendly reference in the Library for f-string. More like Logging Cookbook rather than Logging Howto.

!) above is similar to what you propose ... but different-ish.

[0] https://docs.python.org/dev/tutorial/inputoutput.html#formatted-string-literals
[1] https://docs.python.org/dev/reference/lexical_analysis.html#f-strings
[2] https://docs.python.org/dev/search.html?q=fstring
[3] https://docs.python.org/dev/search.html?q=f-string
[4] https://docs.python.org/dev/library/stdtypes.html#printf-style-bytes-formatting
[5] https://docs.python.org/dev/library/stdtypes.html#str.format

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Thu Jul 30 01:36:36 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 30 Jul 2020 05:36:36 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1596087396.8.0.473365047119.issue41401@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

The 'master' branch bot is working again, the 3.9 branch is still broken, and the 3.8 branch seems, as yet, unaffected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Thu Jul 30 02:06:45 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 06:06:45 +0000
Subject: [issue41439] some test cases in test_uuid.py and test_ssl.py fail on
 some operating systems because of no os.fork support
Message-ID: <1596089205.38.0.465991237875.issue41439@roundup.psfhosted.org>


New submission from Peixing Xin <peixing.xin at windriver.com>:

Some operating systems, for example VxWorks RTOS, don't support fork(). Some test cases that depend on os.fork() will fail. 
test_ssl.BasicSocketTests.test_random_fork and test_uuid.TestUUIDWithExtModule.testIssue8621 fail are this case.

----------
components: Tests
messages: 374599
nosy: pxinwr
priority: normal
severity: normal
status: open
title: some test cases in test_uuid.py and test_ssl.py fail on some operating systems because of no os.fork support
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41439>
_______________________________________

From report at bugs.python.org  Thu Jul 30 02:10:11 2020
From: report at bugs.python.org (Hilit Oreny)
Date: Thu, 30 Jul 2020 06:10:11 +0000
Subject: [issue40045] Make "dunder" method documentation easier to locate
In-Reply-To: <1584924633.15.0.655954011008.issue40045@roundup.psfhosted.org>
Message-ID: <1596089411.94.0.292326337325.issue40045@roundup.psfhosted.org>


Hilit Oreny <hilit.oreny at gmail.com> added the comment:

This issue has been resolved (thanks to @javadmokhtari and @nanjekyejoannah), but its Status is still "open" and the Resolution is blank...
Members of Python triage team, please change the Status to "closed" and  the Resolution to "fixed".
Thank you!

----------
nosy: +HO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40045>
_______________________________________

From report at bugs.python.org  Thu Jul 30 02:17:52 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 06:17:52 +0000
Subject: [issue41439] some test cases in test_uuid.py and test_ssl.py fail on
 some operating systems because of no os.fork support
In-Reply-To: <1596089205.38.0.465991237875.issue41439@roundup.psfhosted.org>
Message-ID: <1596089872.02.0.222344824211.issue41439@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
keywords: +patch
pull_requests: +20827
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21684

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41439>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:07:44 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 07:07:44 +0000
Subject: [issue41440] os.cpu_count doesn't work on VxWorks RTOS
Message-ID: <1596092864.05.0.11139024599.issue41440@roundup.psfhosted.org>


New submission from Peixing Xin <peixing.xin at windriver.com>:

Now os.cpu_count() always returns NONE on VxWorks RTOS. It needs to be fixed particularly for VxWorks.

----------
components: Library (Lib)
messages: 374601
nosy: pxinwr
priority: normal
severity: normal
status: open
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41440>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:17:03 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 07:17:03 +0000
Subject: [issue41440] os.cpu_count doesn't work on VxWorks RTOS
In-Reply-To: <1596092864.05.0.11139024599.issue41440@roundup.psfhosted.org>
Message-ID: <1596093423.19.0.349998817596.issue41440@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
keywords: +patch
pull_requests: +20828
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21685

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41440>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:30:53 2020
From: report at bugs.python.org (Thomas Holder)
Date: Thu, 30 Jul 2020 07:30:53 +0000
Subject: [issue40075] _tkinter PythonCmd fails to acquire GIL
In-Reply-To: <1585224969.87.0.649895216825.issue40075@roundup.psfhosted.org>
Message-ID: <1596094253.76.0.181455654724.issue40075@roundup.psfhosted.org>


Thomas Holder <thomas.holder at schrodinger.com> added the comment:

Attaching an even simpler example which doesn't use PyQt. It shows a native Windows dialog using ctypes. I could not reproduce the crash without showing any non-tk dialog.

Steve's explanation sounds plausible.

----------
Added file: https://bugs.python.org/file49349/simple_tk_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40075>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:33:10 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 30 Jul 2020 07:33:10 +0000
Subject: [issue37586] macOS: posix_spawn(..., setsid=True)
In-Reply-To: <1563024457.33.0.250849204696.issue37586@roundup.psfhosted.org>
Message-ID: <1596094390.0.0.885656343693.issue37586@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That's this issue.

FWIW: I'm slowly working on a patch to build on macOS 11 and deploy to macOS 10.9 or later, the current rough and untested PR is at https://github.com/python/cpython/pull/21583. 

This needs testing and cleanup before it can be considered for merging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37586>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:58:26 2020
From: report at bugs.python.org (Brett Hannigan)
Date: Thu, 30 Jul 2020 07:58:26 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1596095906.58.0.265673644151.issue41177@roundup.psfhosted.org>


Brett Hannigan <brett.hannigan at gmail.com> added the comment:

Just wanted to check-in to see if there were any updates on my proposed PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Thu Jul 30 04:42:51 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Thu, 30 Jul 2020 08:42:51 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
Message-ID: <1596098571.51.0.839262162281.issue41441@roundup.psfhosted.org>


Change by ??? <ke265379ke at gmail.com>:


----------
components: IO
nosy: ke265379ke
priority: normal
severity: normal
status: open
title: io  reading ? updating fix
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 04:48:13 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Thu, 30 Jul 2020 08:48:13 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
Message-ID: <1596098893.17.0.520605278787.issue41441@roundup.psfhosted.org>


Change by ??? <ke265379ke at gmail.com>:


----------
keywords: +patch
pull_requests: +20829
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 04:50:02 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Thu, 30 Jul 2020 08:50:02 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
Message-ID: <1596099002.73.0.0712863511009.issue41441@roundup.psfhosted.org>


New submission from ??? <ke265379ke at gmail.com>:

happen at io's reading & updating(r+) mode
if you remove whole content ( truncate(0) ), tell wil not back to 0
then you start writing will start at current position
that's why problem happen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 04:57:10 2020
From: report at bugs.python.org (Sebastien Williams-Wynn)
Date: Thu, 30 Jul 2020 08:57:10 +0000
Subject: [issue41395] pickle and pickletools cli interface doesn't close input
 and output file.
In-Reply-To: <1595686330.63.0.838691465271.issue41395@roundup.psfhosted.org>
Message-ID: <1596099430.86.0.191818764721.issue41395@roundup.psfhosted.org>


Change by Sebastien Williams-Wynn <s.williamswynn.mail at gmail.com>:


----------
nosy: +s.williams-wynn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41395>
_______________________________________

From report at bugs.python.org  Thu Jul 30 04:58:51 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Thu, 30 Jul 2020 08:58:51 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
In-Reply-To: <1596099002.73.0.0712863511009.issue41441@roundup.psfhosted.org>
Message-ID: <1596099531.87.0.233384875637.issue41441@roundup.psfhosted.org>


Change by ??? <ke265379ke at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:04:04 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 30 Jul 2020 09:04:04 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
In-Reply-To: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>
Message-ID: <1596099844.55.0.837338555843.issue41323@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:03:27 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 30 Jul 2020 09:03:27 +0000
Subject: [issue41323] Perform "peephole" optimization directly on control-flow
 graph.
In-Reply-To: <1594981622.83.0.602836344044.issue41323@roundup.psfhosted.org>
Message-ID: <1596099807.7.0.120264211057.issue41323@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 6e8128f02e1d36e38e5866f9dc36e051caa47bc9 by Mark Shannon in branch 'master':
bpo-41323: Perform 'peephole' optimizations directly on the CFG. (GH-21517)
https://github.com/python/cpython/commit/6e8128f02e1d36e38e5866f9dc36e051caa47bc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41323>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:32:35 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Thu, 30 Jul 2020 09:32:35 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
In-Reply-To: <1596099002.73.0.0712863511009.issue41441@roundup.psfhosted.org>
Message-ID: <1596101555.27.0.3832738371.issue41441@roundup.psfhosted.org>


??? <ke265379ke at gmail.com> added the comment:

Please refer to the test case-  https://github.com/841020/open_source

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:56:02 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Jul 2020 09:56:02 +0000
Subject: [issue40075] _tkinter PythonCmd fails to acquire GIL
In-Reply-To: <1585224969.87.0.649895216825.issue40075@roundup.psfhosted.org>
Message-ID: <1596102962.59.0.393420424359.issue40075@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Thanks Steve for your explanation. I had a quick experiment with the ENTER_PYTHON definition and initially just added a call to PyThreadState_Get if the tstate was NULL. This still crashed the interpreter with the following error (which I think reaffirms Steve's explanation):

Fatal Python error: PyThreadState_Get: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)

To work-around this error, I temporarily acquired the GIL and then released it after the call to PyThreadState_Get. The result worked correctly and can be found in the attached diff. I am not saying that the attached diff is the solution, but I don't think we need to stop using tstate in favour of the gstate introduced in the PR.

> I could not reproduce the crash without showing any non-tk dialog.

That would help explain why I cannot reproduce it on Linux - it is differences in the windowing API under Tcl not some platform-specific code in Tcl/Tk or _tkinter.

----------
Added file: https://bugs.python.org/file49350/tstate_acquire.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40075>
_______________________________________

From report at bugs.python.org  Thu Jul 30 06:05:24 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 10:05:24 +0000
Subject: [issue41442] test_posix.PosixTester.test_getgroups fail on operating
 systems without supporting unix shell
Message-ID: <1596103524.36.0.943373328991.issue41442@roundup.psfhosted.org>


New submission from Peixing Xin <peixing.xin at windriver.com>:

test_posix.PosixTester.test_getgroups requires unix shell supported on tested platform. However some operating systems like VxWorks doesn't support unix shell. This case will fail on it.

----------
components: Tests
messages: 374609
nosy: pxinwr
priority: normal
severity: normal
status: open
title: test_posix.PosixTester.test_getgroups fail on operating systems without supporting unix shell
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41442>
_______________________________________

From report at bugs.python.org  Thu Jul 30 06:06:55 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Thu, 30 Jul 2020 10:06:55 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
In-Reply-To: <1596099002.73.0.0712863511009.issue41441@roundup.psfhosted.org>
Message-ID: <1596103615.65.0.954657546414.issue41441@roundup.psfhosted.org>


Change by ??? <ke265379ke at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 06:11:47 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 10:11:47 +0000
Subject: [issue41442] test_posix.PosixTester.test_getgroups fail on operating
 systems without supporting unix shell
In-Reply-To: <1596103524.36.0.943373328991.issue41442@roundup.psfhosted.org>
Message-ID: <1596103907.77.0.243128437401.issue41442@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
keywords: +patch
pull_requests: +20830
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41442>
_______________________________________

From report at bugs.python.org  Thu Jul 30 06:49:02 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 10:49:02 +0000
Subject: [issue41443] some test cases in test_posix.py fail if some os
 attributes are not supported
Message-ID: <1596106142.56.0.534494527465.issue41443@roundup.psfhosted.org>


New submission from Peixing Xin <peixing.xin at windriver.com>:

Some operating systems like VxWorks can't support posix.chown, posix.mknod and posix.readlink. This results that test_chown_dir_fd, test_mknod_dir_fd and test_readlink_dir_fd fail.

----------
components: Tests
messages: 374610
nosy: pxinwr
priority: normal
severity: normal
status: open
title: some test cases in test_posix.py fail if some os attributes are not supported
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41443>
_______________________________________

From report at bugs.python.org  Thu Jul 30 06:56:22 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 30 Jul 2020 10:56:22 +0000
Subject: [issue41443] some test cases in test_posix.py fail if some os
 attributes are not supported
In-Reply-To: <1596106142.56.0.534494527465.issue41443@roundup.psfhosted.org>
Message-ID: <1596106582.48.0.607837276998.issue41443@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
keywords: +patch
pull_requests: +20831
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21688

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41443>
_______________________________________

From report at bugs.python.org  Thu Jul 30 07:11:47 2020
From: report at bugs.python.org (David Halter)
Date: Thu, 30 Jul 2020 11:11:47 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596107507.79.0.994572405674.issue40360@roundup.psfhosted.org>


David Halter <davidhalter88 at gmail.com> added the comment:

@gvanrossum

> Does parso have to be pure Python? If not, we could generate C code like we do for CPython's parser. 

I would rather write the parser either in C or Rust. So no, parso does not need to be pure Python.

> Now, that doesn't work for incremental parsing, but I did an alternative implementation that uses a stack machine, also in C, that's only 2x slower than the PEG parser. Maybe that could be adapted to incremental parsing (because it's a stack machine). Error recovery is still a research project (at least for me -- I'm actually reading papers :-).

Makes sense! I was also thinking about GLL parsing. Obviously GLL does not cover all cases where PEG could potentially work, but I doubt that Python ever moves to a place where GLL would not be sufficient.

I'm also doing a bit of research on Rust parsers and trying to find a solution for my parsing needs in the future. (I'd rather have a Rust parser than a C one, because I like the language better and both should still work in Python).

Please let me know if you're making a lot of progress with PEG parsers and error recovery/incremental parsing. I'm definitely interested in copying an approach if it works :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Jul 30 07:36:20 2020
From: report at bugs.python.org (Julien Danjou)
Date: Thu, 30 Jul 2020 11:36:20 +0000
Subject: [issue41435] Allow to retrieve ongoing exception handled by every
 threads
In-Reply-To: <1596037186.46.0.97878619969.issue41435@roundup.psfhosted.org>
Message-ID: <1596108980.4.0.166124779018.issue41435@roundup.psfhosted.org>


Change by Julien Danjou <julien at danjou.info>:


----------
keywords: +patch
pull_requests: +20832
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21689

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41435>
_______________________________________

From report at bugs.python.org  Thu Jul 30 07:52:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Jul 2020 11:52:49 +0000
Subject: [issue40045] Make "dunder" method documentation easier to locate
In-Reply-To: <1584924633.15.0.655954011008.issue40045@roundup.psfhosted.org>
Message-ID: <1596109969.15.0.188944967575.issue40045@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing as fixed. Thanks Hilit.

----------
nosy: +xtreak
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40045>
_______________________________________

From report at bugs.python.org  Thu Jul 30 08:34:50 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 30 Jul 2020 12:34:50 +0000
Subject: [issue41411] Improve and consolidate f-strings docs
In-Reply-To: <1595867493.01.0.94068638385.issue41411@roundup.psfhosted.org>
Message-ID: <1596112490.58.0.0645403324764.issue41411@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks both for pointing out the additional section in inputoutput.rst that I initially missed.

> I have done PR 21681 that adds index to the tutorial although searching[2][3] does not seem to be better now that the reference has an index.

The online docs seem updated, so I'm not sure why it's not working. Maybe you could try moving things around and see if you can make it work?  You should be able to build the docs locally and test from there.  You can also see if Sphinx raises any warning during the build process, try to move the `.. index` directive just after the section title (instead of before), or add an empty line between the list of entries and the section label (unnecessary if you move the entries after the title). 

> This is there[0] but it _IS_ hard to find, when you don't know it is there.

I noticed (or rather, I didn't :)!

> It may not be very "introduction-y", and if you like I can make a go at trying to reword it.

I think this section is fine, the only thing that needs to be update is the link at the end of the section to point to the main f-string section that we will add elsewhere.

>> The stdtypes page is already quite long and crowded ...
> True. But is this wrong? In my feeling this is reference documentation. It should be accurate, complete and clear. It may not need to be "textbook-like".

You might be right.

> Some thoughts:
> - There may be benefit in reorganising stdtypes.rst to improve the flow without changing the actual content. This could mean breaking it up into a number of documents rather than the monolith it is.

Both in the documentation and in the code, there are advantages in having everything on a single page/file (such as easier ctrl+f search) but also disadvantages.  Given the goal of the page, I think keeping it monolithic is fine: it provides a summary of all the built-in types in a single place.  Breaking it down into multiple pages will have other issues.  If you make a page per type, you will have some pages that are very short, and it will be more difficult to get an overview of all the types, comparing them, and searching through all of them at once. 

> - It does feel like printf[4] was plugged in later because str.format()[5] had been explained earlier. (Although I believe printf came before str.format()). A first time reader of the document will find it hard to know the one way that is right when it comes to formatting.

If I recall correctly that section has also been there, but initially it was just describing the standard way of doing string formatting, and when str.format() was added, it got renamed and the note at the top was added to link to the str.format() documentation.  I guess that the str.format documentation ended up in string.rst because it was related to string.formatter, and the author wanted to keep them together.

> - f-strings should probably also be described here because it _is_ built in, no? It may not be accurate to say it is in /Lib/strings. There is no reference that a developer can just look at to remind/confirm to themselves how to "do it".

Agreed, stdtypes.rst would be the right place where to document this, my only concerns were: 1) the size of the page (that as said above, is not such a big deal); 2) keeping str.format() and string.Formatter() together (but this is also not a huge concern).

Also note that str.format() is not documented in stdtypes.rst, however there is an entry for str.format() with a clear link to the formatting docs, so I never had a problem finding it, even if I needed an extra click.

[...]

> But now (and this is mainly to me) it appears that another problem is a need to consistently, clearly, and in one place describe the various elements/nuances/eccentricities of presenting data in Python: 
>  - string
>  - string.Formatter,
>  - string.Template,
>  - str.format()
>  - f-string
>  - Format Specification Mini-Language
>  - maybe even __format__ and conversion?
>  - etc

What about doing the following:
* keep having stdtypes.rst cover and explain all the built-in types and their features;
* move the "Format String Syntax", "Format Specification Mini-Language", "Format examples" sections from string.rst to stdtypes.rst where they belong;
* integrate f-strings in these sections, and add a new section explaining f-string-specific quirks;
* leave the printf-style string formatting in stdtypes.rst, after the format sections
* use string.rst to document the string module and its objects, hence leaving string.Formatter and string.Template here, where they belong (string.Formatter is self contained enough that doesn't need to be with the other format sections);
* leave the inputoutput.rst and lexical_analysis pages as they are;
* update the introduction.rst page to mention f-string;
* once all this is done, update all links to point to the appropriate sections and cross-link all related sections;


> I propose one of the following two:
> 1) A new section in Library documentation just to handle strings, then systematically removing them elsewhere.(Built-In Functions, Built-In Types, Text Processing Services)

Doing this would leave a gap in the built-in types page, and you would still want things things like string.Formatter and string.Template to be documented in string.rst.  It also raises the question: where should we put this page?

> 2) We take all that Python history and explain it in a HOWTO, and add a developer friendly reference in the Library for f-string. More like Logging Cookbook rather than Logging Howto.

One of the reasons why I'm not fond of the HOWTO idea, is that these are built-in features that need to be documented in the main documentation, where the string type is documented.  It is my understanding that the HOWTOs are mostly meant as standalone (and somewhat external) additions that cover a specific topic in detail.  While having an HOWTO on all the quirks and options for doing string formatting in Python does make sense, we would still have to cover it in the main docs, thus ending up duplicating a lot.  For example the argparse tutorial (one of the HOWTOs), shows actual examples of how to use argparse, but the module itself and its API are already extensively documented in the argparse module documentation.

The only way I could see it working is if we turned the "Format Examples" section in an HOWTO and add more examples specific to f-string, however when I wrote that section I think I tried to cover all the features and the end result was compact enough to fit in a single section.  I'm also not sure there's much value in adding more examples and documentation about the old string formatting, string.Formatter, and string.Template, since nowadays they are rarely used (especially the last two).


There are also another couple of thoughts I had, that however I haven't fully developed yet (so it's better to deal with them later or in another issue):
* str.format() is still used in a lot of places in the docs, where f-strings could be used instead.  These should be updated to use f-string;
* format(), str.format(), and f-string, have quite a lot of overlapping, but I'm not sure what's the best way to document them clearly without unnecessary repetition.  I have a feeling that documenting the format mini-language and using f-string for the features shared by all three might be the best option -- additional examples that are specific to format(), str.format(), and f-strings, can then be added separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41411>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:14:58 2020
From: report at bugs.python.org (=?utf-8?b?0JLQsNC00LjQvCDQndC+0LLQuNC60L7Qsg==?=)
Date: Thu, 30 Jul 2020 13:14:58 +0000
Subject: [issue41360] method _tunnel does not allow for a standard proxy
 authentication solution
In-Reply-To: <1595339881.01.0.101864505877.issue41360@roundup.psfhosted.org>
Message-ID: <1596114898.66.0.33006234767.issue41360@roundup.psfhosted.org>


Change by ????? ??????? <rk5novikov at gmail.com>:


----------
nosy: +????? ???????

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41360>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:23:44 2020
From: report at bugs.python.org (Vladislav Mikhalin)
Date: Thu, 30 Jul 2020 13:23:44 +0000
Subject: [issue41444] CPython 3.8.5 fails to build on Windows with -E option
Message-ID: <1596115424.63.0.60743816933.issue41444@roundup.psfhosted.org>


New submission from Vladislav Mikhalin <mikhalinvlad at gmail.com>:

These errors are generated on a clean build:

C:\cpython-3.8.5\Modules\_ctypes\_ctypes.c(107,10): fatal error C1083: Cannot open include file: 'ffi.h': No such file or directory [C:\cpython-3.8.5\PCbuild\_ctypes.vcxproj]
C:\cpython-3.8.5\Modules\_ctypes\callbacks.c(4,10): fatal error C1083: Cannot open include file: 'ffi.h': No such file or directory [C:\cpython-3.8.5\PCbuild\_ctypes.vcxproj]
C:\cpython-3.8.5\Modules\_ctypes\callproc.c(71,10): fatal error C1083: Cannot open include file: 'ffi.h': No such file or directory [C:\cpython-3.8.5\PCbuild\_ctypes.vcxproj]
C:\cpython-3.8.5\Modules\_ctypes\cfield.c(3,10): fatal error C1083: Cannot open include file: 'ffi.h': No such file or directory [C:\cpython-3.8.5\PCbuild\_ctypes.vcxproj]
C:\cpython-3.8.5\Modules\_ctypes\malloc_closure.c(2,10): fatal error C1083: Cannot open include file: 'ffi.h': No such file or directory [C:\cpython-3.8.5\PCbuild\_ctypes.vcxproj]
C:\cpython-3.8.5\Modules\_ctypes\stgdict.c(2,10): fatal error C1083: Cannot open include file: 'ffi.h': No such file or directory [C:\cpython-3.8.5\PCbuild\_ctypes.vcxproj]

----------
components: Build
messages: 374614
nosy: Vladislav Mikhalin
priority: normal
severity: normal
status: open
title: CPython 3.8.5 fails to build on Windows with -E option
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41444>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:36:26 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Jul 2020 13:36:26 +0000
Subject: [issue41444] CPython 3.8.5 fails to build on Windows with -E option
In-Reply-To: <1596115424.63.0.60743816933.issue41444@roundup.psfhosted.org>
Message-ID: <1596116186.02.0.915557017541.issue41444@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41444>
_______________________________________

From report at bugs.python.org  Thu Jul 30 10:25:30 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 30 Jul 2020 14:25:30 +0000
Subject: [issue40841] Provide mimetypes.sniff API as stdlib
In-Reply-To: <1591080165.24.0.514984320107.issue40841@roundup.psfhosted.org>
Message-ID: <1596119130.88.0.116804457729.issue40841@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

https://www.garykessler.net/library/file_sigs.html looks like a good resource for this kind of API.

However, I would like to choose well-known standard from whatwg or w3c etc..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40841>
_______________________________________

From report at bugs.python.org  Thu Jul 30 10:48:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 30 Jul 2020 14:48:43 +0000
Subject: [issue41330] Inefficient error-handle for CJK encodings
In-Reply-To: <1595048019.57.0.348575052072.issue41330@roundup.psfhosted.org>
Message-ID: <1596120523.61.0.00715095370541.issue41330@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I am also +1 on Serhiy's opinion.

As I am Korean, (I don't know Japan or China environment)
I know that there still exist old Korean websites that use EUC-KR encoding.
But at least 2010s modern Korea website/application.
Most of the applications are built on UTF-8.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41330>
_______________________________________

From report at bugs.python.org  Thu Jul 30 11:47:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Jul 2020 15:47:49 +0000
Subject: [issue41444] CPython 3.8.5 fails to build on Windows with -E option
In-Reply-To: <1596115424.63.0.60743816933.issue41444@roundup.psfhosted.org>
Message-ID: <1596124069.34.0.245335053873.issue41444@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yes, if you use -E then you need to provide the dependencies in some other way.

The option is there to suppress network access at build time, not to build without those modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41444>
_______________________________________

From report at bugs.python.org  Thu Jul 30 12:07:13 2020
From: report at bugs.python.org (Vladislav Mikhalin)
Date: Thu, 30 Jul 2020 16:07:13 +0000
Subject: [issue41444] CPython 3.8.5 fails to build on Windows with -E option
In-Reply-To: <1596115424.63.0.60743816933.issue41444@roundup.psfhosted.org>
Message-ID: <1596125233.44.0.227534356055.issue41444@roundup.psfhosted.org>


Vladislav Mikhalin <mikhalinvlad at gmail.com> added the comment:

The documentation states:
  -E  Don't fetch or build external libraries.  Extension modules that
      depend on external libraries will not attempt to build if this flag
      is present; -e is also accepted to explicitly enable fetching and
      building externals.

So, according to this, any module that is dependent on external libraries will not be built. Ant it was working with 3.7.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41444>
_______________________________________

From report at bugs.python.org  Thu Jul 30 12:23:51 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Thu, 30 Jul 2020 16:23:51 +0000
Subject: [issue41445] Adding configure temporary files to gitignore
Message-ID: <1596126231.09.0.21986498647.issue41445@roundup.psfhosted.org>


New submission from fj92f3jj923f923 <watashiwaher at gmail.com>:

I noticed that a lot of files generated and removed due configuring.
I was too scary, when I saw them, and decided to add them to .gitignore.

----------
components: Build
messages: 374619
nosy: fj92f3jj923f923
priority: normal
severity: normal
status: open
title: Adding configure temporary files to gitignore
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41445>
_______________________________________

From report at bugs.python.org  Thu Jul 30 12:25:02 2020
From: report at bugs.python.org (fj92f3jj923f923)
Date: Thu, 30 Jul 2020 16:25:02 +0000
Subject: [issue41445] Adding configure temporary files to gitignore
In-Reply-To: <1596126231.09.0.21986498647.issue41445@roundup.psfhosted.org>
Message-ID: <1596126302.13.0.475982908238.issue41445@roundup.psfhosted.org>


Change by fj92f3jj923f923 <watashiwaher at gmail.com>:


----------
keywords: +patch
pull_requests: +20833
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21691

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41445>
_______________________________________

From report at bugs.python.org  Thu Jul 30 13:18:47 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Thu, 30 Jul 2020 17:18:47 +0000
Subject: [issue41446] New demo, using a web api
Message-ID: <1596129527.79.0.745234109519.issue41446@roundup.psfhosted.org>


New submission from Juan Jimenez <flybd5 at gmail.com>:

As per a suggestion in https://bugs.python.org/issue41274 I would like to submit for consideration a new demo program, one that demonstrates how to use a web API to generate a pseudo-random generator seed from high resolution, high cadence images of the sun. I will be submitting a pull request for consideration.

----------
components: Demos and Tools
messages: 374620
nosy: flybd5
priority: normal
severity: normal
status: open
title: New demo, using a web api
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41446>
_______________________________________

From report at bugs.python.org  Thu Jul 30 13:19:35 2020
From: report at bugs.python.org (Damian Barabonkov)
Date: Thu, 30 Jul 2020 17:19:35 +0000
Subject: [issue41447] Resource Tracker in Multiprocessing Shared Memory not
 working correctly
Message-ID: <1596129575.64.0.828449737414.issue41447@roundup.psfhosted.org>


New submission from Damian Barabonkov <damianb at mit.edu>:

The way the resource tracker is used in /Lib/multiprocessing/shared_memory.py leads to it issuing warnings/errors, even when resources are cleaned up properly.

Attached are two simple demo files copied from the documentation example (https://docs.python.org/3.9/library/multiprocessing.shared_memory.html) that illustrate the warnings below: 

proc1.py

Traceback (most recent call last):
  File "proc1.py", line 19, in <module>
    shm.unlink()  # Free and release the shared memory block at the very end
  File "/home/damian/Documents/QuantCo/miniconda3/envs/pipeline-parallel/lib/python3.8/multiprocessing/shared_memory.py", line 244, in unlink
    _posixshmem.shm_unlink(self._name)
FileNotFoundError: [Errno 2] No such file or directory: '/shmem'
/home/damian/Documents/QuantCo/miniconda3/envs/pipeline-parallel/lib/python3.8/multiprocessing/resource_tracker.py:218: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/home/damian/Documents/QuantCo/miniconda3/envs/pipeline-parallel/lib/python3.8/multiprocessing/resource_tracker.py:231: UserWarning: resource_tracker: '/shmem': [Errno 2] No such file or directory: '/shmem'
  warnings.warn('resource_tracker: %r: %s' % (name, e))


proc2.py

python3.8/multiprocessing/resource_tracker.py:218: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '

----------
files: shmem_bug.py
messages: 374621
nosy: damian.barabonkov
priority: normal
severity: normal
status: open
title: Resource Tracker in Multiprocessing Shared Memory not working correctly
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49351/shmem_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41447>
_______________________________________

From report at bugs.python.org  Thu Jul 30 14:16:47 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 30 Jul 2020 18:16:47 +0000
Subject: [issue20684] inspect.getfullargspec (etc) incorrectly follows
 __wrapped__ chains
In-Reply-To: <1392813621.68.0.712139176055.issue20684@psf.upfronthosting.co.za>
Message-ID: <1596133007.34.0.954185432667.issue20684@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile
nosy_count: 3.0 -> 4.0
pull_requests: +20834
pull_request: https://github.com/python/cpython/pull/21100

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20684>
_______________________________________

From report at bugs.python.org  Thu Jul 30 16:27:49 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Jul 2020 20:27:49 +0000
Subject: [issue41131] Augment random.choices() with the alias method
In-Reply-To: <1593203921.14.0.316410898298.issue41131@roundup.psfhosted.org>
Message-ID: <1596140869.89.0.17576207927.issue41131@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm not clear on that the alias method is valuable here. Because of the preprocessing expense, it cries out for a class instead: an object that can retain the preprocessed tables, be saved to disk (pickled), restored later, and used repeatedly to make O(1) selections. I have such a class, which uses exact integer arithmetic (e.g., during preprocessing, there's at least one "too small" bin if and only if there's at least one "too large" bin), and is as unbiased as choice() and randrange(). Reasoning about float vagaries is much harder, and I see no error analysis here.

Most troubling: that due to rounding, reducing a "too large" bin results in a weight that spuriously compares <= bin_size. Then a "too small" bin with a genuinely tiny weight can be left with nothing to pair with, and so ends up aliasing itself, giving it a massively too-high probability of being picked.

So if you're determined to stick to "a function", I'd stick to the simple inverse CDF sampling method.  Unless the number of choices is "very" large, the log factor doesn't much matter.

That said, the alias numerics here could be improved some by working with the weights directly, "normalizing" them only at the end.  Instead of comparing weights to bin_size, compare them instead to the mean:

mean = total / n

(note: the next step to getting rid of floats entirely is to pre-multiply the weights by lcm(total, n) // total  - then their mean is exactly the integer lcm(total, n) // n).

The mean (instead of bin_size) suffers rounding errors then, but the original weights don't during the "hard part" of preprocessing.  At the end,

fn = n + 0.0
U = [weights[i] / total + i / fn for i in range(n)]

instead.  The "i / fn" also suffers just one rounding error as opposed to the two in the current "bin_width * i".  That can make a difference for n as small as 5:

>>> 3/5
0.6
>>> (1/5)*3
0.6000000000000001

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41131>
_______________________________________

From report at bugs.python.org  Thu Jul 30 16:32:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Jul 2020 20:32:15 +0000
Subject: [issue37586] macOS: posix_spawn(..., setsid=True)
In-Reply-To: <1563024457.33.0.250849204696.issue37586@roundup.psfhosted.org>
Message-ID: <1596141135.0.0.225873405278.issue37586@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Oh great, it's one of these style changes :)

You probably want to define some macros for those barriers so the added optional nesting doesn't come back to bite us later.

Otherwise, best of luck! Let me know if I can help out (for now I'm just ignoring the setsid test).

----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37586>
_______________________________________

From report at bugs.python.org  Thu Jul 30 19:40:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Jul 2020 23:40:09 +0000
Subject: [issue41131] Augment random.choices() with the alias method
In-Reply-To: <1593203921.14.0.316410898298.issue41131@roundup.psfhosted.org>
Message-ID: <1596152409.25.0.729743021114.issue41131@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Okay, thank you for looking!

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41131>
_______________________________________

From report at bugs.python.org  Thu Jul 30 19:49:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Jul 2020 23:49:21 +0000
Subject: [issue41131] Augment random.choices() with the alias method
In-Reply-To: <1593203921.14.0.316410898298.issue41131@roundup.psfhosted.org>
Message-ID: <1596152961.21.0.178129616119.issue41131@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I paid close attention to rounding.  The reason for the "while small and large" is that the loop stops making aliases unless we have both something at or below 0.5 and something known to be above 0.5.  If we end up with only two bins slightly above over below 0.5, they are considered close-enough and will alias to themselves.

By giving the bins a default alias to themselves, there is always a reasonable dispatch in the main sampling loop even if the random() value compares to an unfavorably rounded entry in U.

The code assumes that weird roundings will happen through out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41131>
_______________________________________

From report at bugs.python.org  Thu Jul 30 20:54:24 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2020 00:54:24 +0000
Subject: [issue6143] IDLE - clear and restart the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1596156864.77.0.0888502295056.issue6143@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

@Pokerstar: First we have to agree on several things.

1. What is the need, what are the use cases? When do *you* feel a need to clear the shell?

2. What is the basic strategy?
 a. Delete selections: make delete, backspace, and cut work in the shell, as in editor.
    I prefer this.  No new doc or menu entries needed.
    People can delele less than everything.
 b. New feature. All or nothing.  Changes 8 files.  There was discussin of how to delete, but seems not difficult.

3. Details need to be agreed on.
  If new feature, menu entry and shortcut: I thing 'Clear shell' is enough.  Patch disagrees with discussion on shortcut.
  Should header be deleted or left?  (Delete selection lets user decide.)
  Should deleted text be undoable?  We do not currently allow any editing of shell history?  Undo amounts to pasting or retyping, and if we do not allow pasting or typing in general, why with undo?
  Should squeezes text be expanded?  I think not.  help(tkinter) produces over 22000 lines.
  Should the current prompt and any code be deleted?  I think not.  If prompt gets deleted, it has to be re-written, but without current in-process entry.
  Should remote process be restarted?  Why?  This can easily be done independently and might not be wanted.
  <probably something else>

4. New behavior must be tested.  The is usually the hardest part of a patch, which is why it is neglected.  Incomplete testing may result in adding a new bug.  It was just reported that closing IDLE while the Shell is waiting for a response to input(prompt) leads to incomplete shutdown and a zombie process.  On macOS, this can lead to a crash and possibly a need to reboot.
  So, should we allow clearing, deletion while user code is executing?  While user code is requesting input?  Or must we prohibit?  I don't know, other than this must be tested at least on Windows and macOS.

Overall, I prefer to use the deletion mechanism we have, rather than add a new one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:34:30 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 31 Jul 2020 01:34:30 +0000
Subject: [issue41131] Augment random.choices() with the alias method
In-Reply-To: <1593203921.14.0.316410898298.issue41131@roundup.psfhosted.org>
Message-ID: <1596159270.14.0.333458664035.issue41131@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Oh yes - I understood the intent of the code.  It's as good an approach to living with floating-point slop in this context as I've seen.  It's not obviously broken.  But neither is it obviously correct, and after a few minutes I didn't see a clear path to rigorously proving it can't break.  In FP, if there's one chance in 2**53 that it _can_ break, it will ;-)

The suggestions I made change none of that:  reducing the number of rounding errors can only help.

OTOH, an all-integer version of the algorithm _can_ be "obviously correct", and can embed asserts to verify that it is.  It can all be done in a single fixed-size list of 3-lists ([weight, value, alias]), swapping entries as needed to keep the 3 regions of interest ("too small", "on the nose", "too large") each contiguous.  Then it's straightforward to prove that you run out of "too small" entries at the same time you run out of "too large" ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41131>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:37:35 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Fri, 31 Jul 2020 01:37:35 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
In-Reply-To: <1596099002.73.0.0712863511009.issue41441@roundup.psfhosted.org>
Message-ID: <1596159455.1.0.68487025924.issue41441@roundup.psfhosted.org>


Change by ??? <ke265379ke at gmail.com>:


----------
pull_requests:  -20829

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:26:46 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Fri, 31 Jul 2020 02:26:46 +0000
Subject: [issue41446] New demo, using a web api
In-Reply-To: <1596129527.79.0.745234109519.issue41446@roundup.psfhosted.org>
Message-ID: <1596162406.56.0.95725251541.issue41446@roundup.psfhosted.org>


Change by Juan Jimenez <flybd5 at gmail.com>:


----------
keywords: +patch
pull_requests: +20835
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21693

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41446>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:28:01 2020
From: report at bugs.python.org (Juan Jimenez)
Date: Fri, 31 Jul 2020 02:28:01 +0000
Subject: [issue41274] Better way to random.seed()?
In-Reply-To: <1594417483.64.0.247162665029.issue41274@roundup.psfhosted.org>
Message-ID: <1596162481.29.0.0859281228812.issue41274@roundup.psfhosted.org>


Juan Jimenez <flybd5 at gmail.com> added the comment:

Pull request https://github.com/python/cpython/pull/21693 created for the demo steven.daprano suggested.

----------
message_count: 8.0 -> 9.0
pull_requests: +20836
pull_request: https://github.com/python/cpython/pull/21693

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41274>
_______________________________________

From report at bugs.python.org  Thu Jul 30 23:00:15 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Fri, 31 Jul 2020 03:00:15 +0000
Subject: =?utf-8?q?=5Bissue41441=5D_io__reading_=EF=BC=86_updating_fix?=
In-Reply-To: <1596099002.73.0.0712863511009.issue41441@roundup.psfhosted.org>
Message-ID: <1596164415.69.0.0584340322146.issue41441@roundup.psfhosted.org>


Change by ??? <ke265379ke at gmail.com>:


----------
pull_requests: +20837
pull_request: https://github.com/python/cpython/pull/21686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41441>
_______________________________________

From report at bugs.python.org  Thu Jul 30 23:26:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jul 2020 03:26:42 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596166002.55.0.315106957974.issue40360@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +20838
pull_request: https://github.com/python/cpython/pull/21694

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Jul 31 00:34:49 2020
From: report at bugs.python.org (James Gray)
Date: Fri, 31 Jul 2020 04:34:49 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1596170089.38.0.936040982757.issue36207@roundup.psfhosted.org>


James Gray <lignicksteo at protonmail.com> added the comment:

Bonjour, je vois que nous ne sommes pas les seuls dans ce cas, nous avons besoin que les robots indexent nos pages html mais qu'elles n'indexent pas celles en /*.php$ ainsi que les ressources PC en PDF. Nous avons tent? en vain plusieurs solutions en passant par le robots.txt ? la racine de notre domaine https://demolinux.org/ mais sans succ?s. Le RobotsParser ne prends pas ces r?gles en compte, merci.

----------
nosy: +Jmgray47

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36207>
_______________________________________

From report at bugs.python.org  Fri Jul 31 03:32:36 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 31 Jul 2020 07:32:36 +0000
Subject: [issue41445] Adding configure temporary files to gitignore
In-Reply-To: <1596126231.09.0.21986498647.issue41445@roundup.psfhosted.org>
Message-ID: <1596180756.14.0.702705125698.issue41445@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Do you know you can use separated build dir?

```
$ mkdir build
$ cd build
$ ../configure --with-pydebug
```

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41445>
_______________________________________

From report at bugs.python.org  Fri Jul 31 04:58:16 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 31 Jul 2020 08:58:16 +0000
Subject: [issue41177] ConvertingList and ConvertingTuple lack iterators and
 ConvertingDict lacks items()
In-Reply-To: <1593558603.02.0.467706950868.issue41177@roundup.psfhosted.org>
Message-ID: <1596185896.56.0.578434985717.issue41177@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks for the PR. I reviewed it and requested changes about 3 weeks ago - you should have received a notification from GitHub when that happened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41177>
_______________________________________

From report at bugs.python.org  Fri Jul 31 05:02:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2020 09:02:10 +0000
Subject: [issue41421] Random.paretovariate sometimes raises ZeroDivisionError
 for small alpha
In-Reply-To: <1595959149.08.0.339696183777.issue41421@roundup.psfhosted.org>
Message-ID: <1596186130.48.0.144076117538.issue41421@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +20839
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41421>
_______________________________________

From report at bugs.python.org  Fri Jul 31 05:28:44 2020
From: report at bugs.python.org (Mond Wan)
Date: Fri, 31 Jul 2020 09:28:44 +0000
Subject: [issue41448] pathlib behave differ between OS
Message-ID: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>


New submission from Mond Wan <victor2wen at gmail.com>:

I have tried 2 functions with different behavior across platform

# as_posix()

In linux platform, as_posix() cannot process window path nicely

* From linux + docker + python:3.8

```
Python 3.8.0 (default, Oct 17 2019, 05:36:36)
[GCC 8.3.0] on linux

>>> winPath = r'\workspace\xxx\test_fixture\user-restore-success.zip'
>>> posixPath = '/workspace/xxx/test_fixture/user-restore-success.zip'
>>> pWIN = pathlib.PurePath(winPath)
>>> pPOSIX = pathlib.PurePath(posixPath)
>>> pWIN.as_posix()
'\\workspace\\xxx\\test_fixture\\user-restore-success.zip'
>>> pPOSIX.as_posix()
'/workspace/xxx/test_fixture/user-restore-success.zip'
```

* From window + powershell + python3.6

```
Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32

>>> winPath = r'\workspace\xxx\test_fixture\user-restore-success.zip'
>>> posixPath = '/workspace/xxx/test_fixture/user-restore-success.zip'
>>> pWIN = pathlib.PurePath(winPath)
>>> pPOSIX = pathlib.PurePath(posixPath)
>>> pWIN.as_posix()
'/workspace/xxx/test_fixture/user-restore-success.zip'
>>> pPOSIX.as_posix()
'/workspace/xxx/test_fixture/user-restore-success.zip'

```

* From MAC

```
>>> winPath = '\\workspace\\xxx\\test_fixture\\user-restore-success.zip'
>>> posixPath = '/workspace/xxx/test_fixture/user-restore-success.zip'
>>> pWIN = pathlib.PurePath(winPath)
>>> pPOSIX = pathlib.PurePath(posixPath)
>>> pWIN.as_posix()
'\\workspace\\xxx\\test_fixture\\user-restore-success.zip'
>>> pPOSIX.as_posix()
'/workspace/xxx/test_fixture/user-restore-success.zip'
```

# resolve()

In window platform, resolve() returns absolute path only if such file is able to locate. Otherwise, it returns
relative path.

In Linux platform, resolve() returns absolute path anyway

* From linux

```
root at b4f03ed3003b:/var/run/lock# python
Python 3.8.0 (default, Oct 17 2019, 05:36:36)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pathlib
>>> p = pathlib.Path('no_exists')
>>> p.resolve()
PosixPath('/run/lock/no_exists')
>>> str(p.resolve())
'/run/lock/no_exits'

```

* From window

```
Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pathlib
>>> p = pathlib.Path('README.md')
>>> p.resolve()
WindowsPath('C:/Users/xxx/PycharmProjects/yyy/README.md')
>>> str(p.resolve())
'C:\\Users\\xxx\\PycharmProjects\\yyy\\README.md'
>>> p = pathlib.Path('no_exists')
>>> p.resolve()
WindowsPath('no_exists')
>>> str(p.resolve())
'no_exists'

```

Also, I have spotted a ticket similar to this one

https://bugs.python.org/issue41357

----------
components: FreeBSD, Windows, macOS
messages: 374632
nosy: Mond Wan, koobs, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib behave differ between OS
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 05:30:00 2020
From: report at bugs.python.org (Mond Wan)
Date: Fri, 31 Jul 2020 09:30:00 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596187800.53.0.344893869038.issue41448@roundup.psfhosted.org>


Change by Mond Wan <victor2wen at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:10:32 2020
From: report at bugs.python.org (Anatoli Babenia)
Date: Fri, 31 Jul 2020 10:10:32 +0000
Subject: [issue41449] An article on Python 3 stdout and stderr output buffering
Message-ID: <1596190232.56.0.383059757324.issue41449@roundup.psfhosted.org>


New submission from Anatoli Babenia <anatoli at rainforce.org>:

It is hard to find info why Python 3 buffers stdout/stderr. The buffering causes problems when debugging Python apps in Docker and Kubernetes, and it is unclear if it is Python 3 who starts to buffer stdout if no tty is attached, it is Docker, or it is Kubernetes.

The only bit of info that could be searched is the description of -u option https://docs.python.org/3.8/using/cmdline.html?#cmdoption-u which is not linked to any article.

The `-u` description also says.

> Changed in version 3.7: The text layer of the stdout and stderr streams now is unbuffered.

However, I don't understand what is the text layers of stdout. And there is no description of behaviour when the output is not attached, and when the output is redirected.

----------
assignee: docs at python
components: Documentation
messages: 374633
nosy: Anatoli Babenia, docs at python
priority: normal
severity: normal
status: open
title: An article on Python 3 stdout and stderr output buffering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41449>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:51:13 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Jul 2020 10:51:13 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596192673.01.0.521085151921.issue40360@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 10.0 -> 11.0
pull_requests: +20840
pull_request: https://github.com/python/cpython/pull/21696

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:51:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jul 2020 10:51:14 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596192674.04.0.198705490771.issue40360@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset cadda52d974937069eeebea1cca4229e2bd400df by Karthikeyan Singaravelan in branch 'master':
bpo-40360: Handle PendingDeprecationWarning in test_lib2to3. (GH-21694)
https://github.com/python/cpython/commit/cadda52d974937069eeebea1cca4229e2bd400df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:56:20 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 31 Jul 2020 10:56:20 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596192980.9.0.738167077204.issue41448@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm not sure what you try to report.

PurePath(...) returns a PureWindowsPath on Windows and an PurePosixPath on other (unix-y) platforms. This explains the difference in behaviour you're seeing for as_posix().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 07:12:47 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 31 Jul 2020 11:12:47 +0000
Subject: [issue37586] macOS: posix_spawn(..., setsid=True)
In-Reply-To: <1563024457.33.0.250849204696.issue37586@roundup.psfhosted.org>
Message-ID: <1596193967.37.0.404741433562.issue37586@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The immediate problem is that the version of Xcode you are using supplies a MacOSX10.15 SDK by default. Since you are running on 10.14, the test passes if you build using a MacOSX10.14 SDK. Either upgrade to 10.15 or grab the 10.14 SDK from a previous version of Xcode or the Command Line Tools (which is all you need to build and test Python) and make that SDK the default.  Ronald's patch will eventually fix that but, unless you are building for a newer OS version on an older OS version, it is still safest to use the SDK version that corresponds to the running system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37586>
_______________________________________

From report at bugs.python.org  Fri Jul 31 07:19:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jul 2020 11:19:14 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596194354.06.0.443652170776.issue40360@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +20841
pull_request: https://github.com/python/cpython/pull/21697

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Jul 31 07:19:42 2020
From: report at bugs.python.org (Mond Wan)
Date: Fri, 31 Jul 2020 11:19:42 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596194382.21.0.993413954819.issue41448@roundup.psfhosted.org>


Mond Wan <victor2wen at gmail.com> added the comment:

Let me clarify my expectation.

# For `as_posix()`

* PureWindowsPath can translate both POSIX path, and WINDOW path to POSIX path via `as_posix()`
    * Therefore, I expect PurePosixPath can translate both platform path to POSIX path via `as_posix()`

* I just tried PurePosixPath() behave same between Window, and the docker.
    * I am sorry for showing misleading information

# For `resolve()`

* In window platform, resolve() returns absolute path only if such file is able to locate. Otherwise, it returns
relative path.

* In Linux platform, resolve() returns absolute path anyway

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 07:27:58 2020
From: report at bugs.python.org (Mond Wan)
Date: Fri, 31 Jul 2020 11:27:58 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596194878.5.0.558900436.issue41448@roundup.psfhosted.org>


Mond Wan <victor2wen at gmail.com> added the comment:

Moreover, output from PurePosixPath.as_posix() is not that straightforward?

Please take a look below example from python3.6 + linux + docker

```
>>> winPath = r'\workspace\xxx\test_fixture\user-restore-success.zip'

>>> pWIN = pathlib.PureWindowsPath(winPath)
>>> pppFromWinPath = pathlib.PurePosixPath(winPath)
>>> pppFromPwp = pathlib.PurePosixPath(pWIN)

>>> pppFromWinPath.as_posix()
'\\workspace\\xxx\\test_fixture\\user-restore-success.zip'
>>> pppFromPwp.as_posix()
'\\/workspace/xxx/test_fixture/user-restore-success.zip'
```

* Construction PurePosixPath from rawString, `as_posix()` gives '\\workspace\\xxx\\test_fixture\\user-restore-success.zip'
* Construction PurePosixPath from PureWindowsPath, `as_posix()` gives '\\/workspace/xxx/test_fixture/user-restore-success.zip'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 08:06:15 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 31 Jul 2020 12:06:15 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596197175.4.0.649140408471.issue41448@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

PureWindowsPath does not know about POSIX paths, it supports the two styles of directory separator that are valid on Windows: '/' and '\'. 

PurePosixPath only supports the single stile of directory separator valid on POSIX systems: '/'. 

On a Posix system backslash is a valid character in a file name and is NOT a directory separator.


The behaviour of Path.resolve() on Windows may or may not be a bug, the documentation is not quite clear. Personally I'd lean toward saying this is a bug, but I defer to a pathlib expert.  Note that path.resolve(strict=True) should raise an error on both platforms when the path does not exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 08:47:01 2020
From: report at bugs.python.org (Mond Wan)
Date: Fri, 31 Jul 2020 12:47:01 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596199621.82.0.885828924098.issue41448@roundup.psfhosted.org>


Mond Wan <victor2wen at gmail.com> added the comment:

Thanks for the clarifications on PurePosixPath(). Now, I know which library I should use to solve my problem.

For resolve() with strict True, I have tried on both platform. They will both raise exception if that file does not exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 09:17:59 2020
From: report at bugs.python.org (R. David Murray)
Date: Fri, 31 Jul 2020 13:17:59 +0000
Subject: [issue41402] email: ContentManager.set_content calls nonexistent
 method encode() on bytes
In-Reply-To: <1595786356.19.0.0772009953039.issue41402@roundup.psfhosted.org>
Message-ID: <1596201479.78.0.779334683715.issue41402@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The fix looks good to me.  Don't know how I made that mistake, and obviously I didn't write a test for it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41402>
_______________________________________

From report at bugs.python.org  Fri Jul 31 09:24:17 2020
From: report at bugs.python.org (Arnaud LIPERINI-DIAZ)
Date: Fri, 31 Jul 2020 13:24:17 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1596201857.38.0.383484245048.issue36207@roundup.psfhosted.org>


Arnaud LIPERINI-DIAZ <contact at vauros.com> added the comment:

Do you have documentation about robotParser ? The robot.txt of this website works fine : https://vauros.com/

----------
nosy: +Arnaud LIPERINI-DIAZ

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36207>
_______________________________________

From report at bugs.python.org  Fri Jul 31 10:17:26 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 31 Jul 2020 14:17:26 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1596205046.95.0.580468162743.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset fe928b32daca184e16ccc0ebdc20314cfa776b98 by Karthikeyan Singaravelan in branch '3.9':
[3.9] bpo-40360: Handle PendingDeprecationWarning in test_lib2to3. (GH-21694) (GH-21697)
https://github.com/python/cpython/commit/fe928b32daca184e16ccc0ebdc20314cfa776b98


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Jul 31 10:24:54 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 31 Jul 2020 14:24:54 +0000
Subject: [issue41448] pathlib behave differ between OS
In-Reply-To: <1596187724.05.0.638155501968.issue41448@roundup.psfhosted.org>
Message-ID: <1596205494.91.0.926771748486.issue41448@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41448>
_______________________________________

From report at bugs.python.org  Fri Jul 31 10:36:27 2020
From: report at bugs.python.org (Alexander Sibiryakov)
Date: Fri, 31 Jul 2020 14:36:27 +0000
Subject: [issue41450] OSError is not documented in ssl library,
 but still can be thrown
Message-ID: <1596206187.31.0.0863049661733.issue41450@roundup.psfhosted.org>


New submission from Alexander Sibiryakov <sixty-one at yandex.ru>:

See stack trace
[07/15/2020 08:51:14.799: ERROR/kafka.producer.sender] Uncaught error in kafka producer I/O thread
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/kafka/producer/sender.py", line 60, in run
self.run_once()
File "/usr/local/lib/python3.6/site-packages/kafka/producer/sender.py", line 160, in run_once
self._client.poll(timeout_ms=poll_timeout_ms)
File "/usr/local/lib/python3.6/site-packages/kafka/client_async.py", line 580, in poll
self._maybe_connect(node_id)
File "/usr/local/lib/python3.6/site-packages/kafka/client_async.py", line 390, in _maybe_connect
conn.connect()
File "/usr/local/lib/python3.6/site-packages/kafka/conn.py", line 426, in connect
if self._try_handshake():
File "/usr/local/lib/python3.6/site-packages/kafka/conn.py", line 505, in _try_handshake
self._sock.do_handshake()
File "/usr/local/lib/python3.6/ssl.py", line 1077, in do_handshake
self._sslobj.do_handshake()
File "/usr/local/lib/python3.6/ssl.py", line 689, in do_handshake
self._sslobj.do_handshake()
OSError: [Errno 0] Error

See docs
https://docs.python.org/3.8/library/ssl.html

and see source code:
https://github.com/python/cpython/blob/3.8/Modules/_ssl.c

Probably the best would be to proceed with using SSLError, but short term OSError could be documented.

----------
assignee: docs at python
components: Documentation
messages: 374644
nosy: docs at python, sibiryakov
priority: normal
severity: normal
status: open
title: OSError is not documented in ssl library, but still can be thrown
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41450>
_______________________________________

From report at bugs.python.org  Fri Jul 31 11:10:28 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jul 2020 15:10:28 +0000
Subject: [issue41450] OSError is not documented in ssl library,
 but still can be thrown
In-Reply-To: <1596206187.31.0.0863049661733.issue41450@roundup.psfhosted.org>
Message-ID: <1596208228.92.0.0203925520264.issue41450@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +SSL

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41450>
_______________________________________

From report at bugs.python.org  Fri Jul 31 11:10:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jul 2020 15:10:49 +0000
Subject: [issue41450] OSError is not documented in ssl library,
 but still can be thrown
In-Reply-To: <1596206187.31.0.0863049661733.issue41450@roundup.psfhosted.org>
Message-ID: <1596208249.07.0.738948418741.issue41450@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41450>
_______________________________________

From report at bugs.python.org  Fri Jul 31 12:38:01 2020
From: report at bugs.python.org (Bryce Drennan)
Date: Fri, 31 Jul 2020 16:38:01 +0000
Subject: [issue34277] EmailPolicy not followed
In-Reply-To: <1532928773.1.0.56676864532.issue34277@psf.upfronthosting.co.za>
Message-ID: <1596213481.61.0.547498477843.issue34277@roundup.psfhosted.org>


Change by Bryce Drennan <python at accounts.brycedrennan.com>:


Removed file: https://bugs.python.org/file47720/test_header_folding.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34277>
_______________________________________

From report at bugs.python.org  Fri Jul 31 12:48:15 2020
From: report at bugs.python.org (Akuli)
Date: Fri, 31 Jul 2020 16:48:15 +0000
Subject: [issue40666] TarFile.add does not support pathlib.Path as a value to
 first argument.
Message-ID: <1596214095.23.0.446616713825.issue40666@roundup.psfhosted.org>


New submission from Akuli <akuviljanen17 at gmail.com>:

TarFile.add seems to support pathlib.Path objects (and other PathLike string paths) starting at Python 3.6, for both name and arcname. The paths go to `os.path` functions that return strings.

Recently typeshed was updated to support passing pathlib.Paths in TarFile.add: https://github.com/python/typeshed/pull/4369

----------
nosy: +Akuli

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40666>
_______________________________________

From report at bugs.python.org  Fri Jul 31 13:03:00 2020
From: report at bugs.python.org (Mariatta)
Date: Fri, 31 Jul 2020 17:03:00 +0000
Subject: [issue40978] Document that typing.SupportsXXX protocols are runtime
 checkable
In-Reply-To: <1592163787.83.0.523481527574.issue40978@roundup.psfhosted.org>
Message-ID: <1596214980.36.0.737999898813.issue40978@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

>  because their runtime results are inconsistent with how Mypy handles them, producing both false positives and false negatives.

@guido or @ivan, do you have further thoughts or additional context to share about the above point?

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40978>
_______________________________________

From report at bugs.python.org  Fri Jul 31 13:09:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 31 Jul 2020 17:09:09 +0000
Subject: [issue40978] Document that typing.SupportsXXX protocols are runtime
 checkable
In-Reply-To: <1596214980.36.0.737999898813.issue40978@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+zp3xYhf-jf-4+cTm5EG+UAf=DdTeo9Q1x1V4yEXv-=g@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I agree with Luciano's conclusion and have nothing to add other than to
encourage him to submit a PR for the docs. (I know he already submitted a
PR to refactor the docs. Honestly I lost track of that one. Luciano, if you
need my review for that one, please ping me.)

On Fri, Jul 31, 2020 at 10:04 AM Mariatta <report at bugs.python.org> wrote:

>
> Mariatta <mariatta at python.org> added the comment:
>
> >  because their runtime results are inconsistent with how Mypy handles
> them, producing both false positives and false negatives.
>
> @guido or @ivan, do you have further thoughts or additional context to
> share about the above point?
>
> ----------
> nosy: +Mariatta
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40978>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40978>
_______________________________________

From report at bugs.python.org  Fri Jul 31 13:22:31 2020
From: report at bugs.python.org (Murray Wilson)
Date: Fri, 31 Jul 2020 17:22:31 +0000
Subject: [issue26791] shutil.move fails to move symlink (Invalid cross-device
 link)
In-Reply-To: <1460912297.17.0.227992133358.issue26791@psf.upfronthosting.co.za>
Message-ID: <1596216151.36.0.900443891288.issue26791@roundup.psfhosted.org>


Murray Wilson <murray.wilson at gmail.com> added the comment:

It also happens when moving a file in linux from an xfs filesystem to a NFS mounted filesystem.

----------
nosy: +Murray Wilson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26791>
_______________________________________

From report at bugs.python.org  Fri Jul 31 14:02:55 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 31 Jul 2020 18:02:55 +0000
Subject: [issue26791] shutil.move fails to move symlink (Invalid cross-device
 link)
In-Reply-To: <1460912297.17.0.227992133358.issue26791@psf.upfronthosting.co.za>
Message-ID: <1596218575.67.0.706390533576.issue26791@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy:  -SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26791>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:33:51 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 01 Aug 2020 00:33:51 +0000
Subject: [issue41451] Class with __weakref__ slot cannot inherit from multiple
 typing.Generic classes
Message-ID: <1596242031.59.0.938089827478.issue41451@roundup.psfhosted.org>


New submission from Joshua Bronson <jabronson at gmail.com>:

This appears to be a bug in Python 3.6 that I hit while trying to add type hints to my bidirectional mapping library (https://bidict.rtfd.io).

Pasting a working, minimal repro below for easier inline viewing, and also attaching for easier downloading and running.

Please let me know if there is a workaround that would allow me to continue to support Python 3.6 after adding type hints without having to remove the use of slots and weak references. I spent a while trying to find one first but was then encouraged to report this by @ethanhs.

Thanks in advance for any pointers you may have.

#!/usr/bin/env python3
"""Repro for Python 3.6 slots + weakref + typing.Generic bug."""

from typing import Iterator, Mapping, MutableMapping, TypeVar
from weakref import ref


KT1 = TypeVar("KT1")
KT2 = TypeVar("KT2")


class Invertible(Mapping[KT1, KT2]):
    """A one-element mapping that is generic in two key types with a reference to its inverse.

    ...which in turn holds a (weak) reference back to it.

        >>> element = Invertible("H", 1)
        >>> element
        <Invertible key1='H' key2=1>
        >>> element.inverse
        <Invertible key1=1 key2='H'>
        >>> element.inverse.inverse
        <Invertible key1='H' key2=1>
        >>> element.inverse.inverse is element
        True

        >>> dict(element.items())
        {'H': 1}
        >>> dict(element.inverse.items())
        {1: 'H'}
        >>> list(element)
        ['H']

    Uses the __slots__ optimization, and uses weakrefs for references in one direction
    to avoid strong reference cycles. And still manages to support pickling to boot!

        >>> from pickle import dumps, loads
        >>> pickled = dumps(element)
        >>> roundtripped = loads(pickled)
        >>> roundtripped
        <Invertible key1='H' key2=1>

    """

    # Each instance has (either a strong or a weak) reference to its
    # inverse instance, which has a (weak or strong) reference back.
    __slots__ = ("_inverse_strong", "_inverse_weak", "__weakref__", "key1", "key2")

    def __init__(self, key1: KT1, key2: KT2) -> None:
        self._inverse_weak = None
        self._inverse_strong = inverse = self.__class__.__new__(self.__class__)
        self.key1 = inverse.key2 = key1
        self.key2 = inverse.key1 = key2
        inverse._inverse_strong = None
        inverse._inverse_weak = ref(self)

    def __len__(self) -> int:
        return 1

    def __iter__(self) -> Iterator[KT1]:
        yield self.key1

    def __getitem__(self, key: KT1) -> KT2:
        if key == self.key1:
            return self.key2
        raise KeyError(key)

    def __repr__(self) -> str:
        return f"<{self.__class__.__name__} key1={self.key1!r} key2={self.key2!r}>"

    @property
    def inverse(self) -> "Invertible[KT2, KT1]":
        """The inverse instance."""
        if self._inverse_strong is not None:
            return self._inverse_strong
        inverse = self._inverse_weak()
        if inverse is not None:
            return inverse
        # Refcount of referent must have dropped to zero,
        # as in `Invertible().inverse.inverse`, so init a new one.
        self._inverse_weak = None
        self._inverse_strong = inverse = self.__class__.__new__(self.__class__)
        inverse.key2 = self.key1
        inverse.key1 = self.key2
        inverse._inverse_strong = None
        inverse._inverse_weak = ref(self)
        return inverse

    def __getstate__(self) -> dict:
        """Needed to enable pickling due to use of __slots__ and weakrefs."""
        state = {}
        for cls in self.__class__.__mro__:
            slots = getattr(cls, '__slots__', ())
            for slot in slots:
                if hasattr(self, slot):
                    state[slot] = getattr(self, slot)
        # weakrefs can't be pickled.
        state.pop('_inverse_weak', None)  # Added back in __setstate__ below.
        state.pop('__weakref__', None)  # Not added back in __setstate__. Python manages this one.
        return state

    def __setstate__(self, state) -> None:
        """Needed because use of __slots__ would prevent unpickling otherwise."""
        for slot, value in state.items():
            setattr(self, slot, value)
        self._inverse_weak = None
        self._inverse_strong = inverse = self.__class__.__new__(self.__class__)
        inverse.key2 = self.key1
        inverse.key1 = self.key2
        inverse._inverse_strong = None
        inverse._inverse_weak = ref(self)


# So far so good, but now let's make a mutable version.
# 
# The following class definition works on Python > 3.6, but fails on 3.6 with
# TypeError: __weakref__ slot disallowed: either we already got one, or __itemsize__ != 0

class MutableInvertible(Invertible[KT1, KT2], MutableMapping[KT1, KT2]):
    """Works on > 3.6, but we don't even get this far on Python 3.6:

        >>> MutableInvertible("H", 1)
        <MutableInvertible key1='H' key2=1>

    """

    __slots__ = ()

    def __setitem__(self, key1: KT1, key2: KT2) -> None:
        self.key1 = self.inverse.key2 = key1
        self.key2 = self.inverse.key1 = key2

    def __delitem__(self, key: KT1) -> None:
        raise KeyError(key)


if __name__ == "__main__":
    import doctest
    doctest.testmod()

----------
components: Library (Lib)
files: repro.py
messages: 374649
nosy: jab
priority: normal
severity: normal
status: open
title: Class with __weakref__ slot cannot inherit from multiple typing.Generic classes
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49352/repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41451>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:45:58 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 01 Aug 2020 01:45:58 +0000
Subject: [issue41451] Class with __weakref__ slot cannot inherit from
 typing.Generic subclass
In-Reply-To: <1596242031.59.0.938089827478.issue41451@roundup.psfhosted.org>
Message-ID: <1596246358.08.0.947837373032.issue41451@roundup.psfhosted.org>


Joshua Bronson <jabronson at gmail.com> added the comment:

It turns out that this bug reproduces with any subclass of the generic type with a weakref slot, even without any multiple inheritance going on.

For example:

class Invertible2(Invertible[KT1, KT2]): pass

is enough to trigger this bug along with the Invertible class in my previous example. Attaching the more minimal repro with this comment, and renaming the issue to remove the reference to multiple inheritance.

----------
title: Class with __weakref__ slot cannot inherit from multiple typing.Generic classes -> Class with __weakref__ slot cannot inherit from typing.Generic subclass
Added file: https://bugs.python.org/file49353/bpo41451-repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41451>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:29:57 2020
From: report at bugs.python.org (Martin Panter)
Date: Sat, 01 Aug 2020 03:29:57 +0000
Subject: [issue41450] OSError is not documented in ssl library,
 but still can be thrown
In-Reply-To: <1596206187.31.0.0863049661733.issue41450@roundup.psfhosted.org>
Message-ID: <1596252597.32.0.0747945621106.issue41450@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Issue 31122 is also open about fixing this long-term, but I agree it would be good to document this quirk / bug.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41450>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:34:14 2020
From: report at bugs.python.org (Ma Lin)
Date: Sat, 01 Aug 2020 03:34:14 +0000
Subject: [issue41452] Inefficient BufferedReader.read(-1)
Message-ID: <1596252854.24.0.567639060257.issue41452@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

BufferedReader's constructor has a `buffer_size` parameter, it's the size of this buffer:

    When reading data from BufferedReader object, a larger
    amount of data may be requested from the underlying raw
    stream, and kept in an internal buffer.
    
    The doc of BufferedReader[1]


If call the BufferedReader.read(size) function:

    1, When `size` is a positive number, it reads `buffer_size`
       bytes from the underlying stream. This is expected behavior.

    2, When `size` is -1, it tries to call underlying stream's
       readall() function [2]. In this case `buffer_size` is not
       be respected.
       
       The underlying stream may be `RawIOBase`, its readall()
       function read `DEFAULT_BUFFER_SIZE` bytes in each read [3].
       
       `DEFAULT_BUFFER_SIZE` currently only 8KB, which is very
       inefficient for BufferedReader.read(-1). If `buffer_size`
       bytes is read every time, will be the expected performance.

Attached file demonstrates this problem.


[1] doc of BufferedReader:
https://docs.python.org/3/library/io.html#io.BufferedReader

[2] BufferedReader.read(-1) tries to call underlying stream's readall() function:
https://github.com/python/cpython/blob/v3.9.0b5/Modules/_io/bufferedio.c#L1538-L1542

[3] RawIOBase.readall() read DEFAULT_BUFFER_SIZE each time:
https://github.com/python/cpython/blob/v3.9.0b5/Modules/_io/iobase.c#L968-L969

----------
components: IO
files: demo.py
messages: 374652
nosy: malin
priority: normal
severity: normal
status: open
title: Inefficient BufferedReader.read(-1)
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49354/demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41452>
_______________________________________