From report at bugs.python.org  Thu Jul  1 03:39:54 2021
From: report at bugs.python.org (Floating Sunfish)
Date: Thu, 01 Jul 2021 07:39:54 +0000
Subject: [New-bugs-announce] [issue44542] Python 3.9.6 Can't Find `coverage`
Message-ID: <1625125194.46.0.647938973687.issue44542@roundup.psfhosted.org>


New submission from Floating Sunfish <sunfishscans at gmail.com>:

`coverage` does not work in Python 3.9.6 (but it does in Python 3.9.5).

It doesn't seem bundled with 3.9.6 because you can install it with `pip` (which normally says that it's already installed and doesn't install anything).

Note that `coverage.exe` and its variants are all present in "C:\Python39\Scripts."

The error I get is:

    Fatal error in launcher: Unable to create process using '"c:\python39\python.exe" "C:\Python39\Scripts\coverage.exe" run --source=. -m unittest -f ': The system cannot find the file specified.

----------
messages: 396811
nosy: sunfishscans
priority: normal
severity: normal
status: open
title: Python 3.9.6 Can't Find `coverage`
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Jul  1 04:49:52 2021
From: report at bugs.python.org (Harry)
Date: Thu, 01 Jul 2021 08:49:52 +0000
Subject: [New-bugs-announce] [issue44543] Remove depreciated logging.warn()
 method
Message-ID: <1625129392.07.0.706475155996.issue44543@roundup.psfhosted.org>


New submission from Harry <harry.lees at gmail.com>:

The logging.warn() method as an alias for logging.warning() is a mysterious function in the logging module, as far as I can tell it was depreciated the minute it was added, originally only added for backwards compatibility.

Up until 3.3 it was undocumented, and after that it was Depreciated and was set to be removed in 3.4 (https://bugs.python.org/issue13235). At this point, I believe this function only serves to create confusion as an obscure alternative to logging.warning() and should probably be removed in 3.11.

----------
components: Library (Lib)
messages: 396813
nosy: Harry-Lees
priority: normal
severity: normal
status: open
title: Remove depreciated logging.warn() method
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul  1 12:24:19 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Thu, 01 Jul 2021 16:24:19 +0000
Subject: [New-bugs-announce] [issue44544] Add full list of possible args to
 textwrap: wrap, fill, shorten
Message-ID: <1625156659.02.0.858532247331.issue44544@roundup.psfhosted.org>


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

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

The 3 functions - wrap, fill, shorten -- have a signature like `(..., **kwargs)`, where kwargs are instance attrs of TextWrap. It would be better to list all possible args in the signature because:

 - more convenient for users rather than scrolling back and forth between description of the function and the list under TextWrap

 - the list under TextWrap is so long it doesn't fit on one screen. It would be great to have a compact list in the signature of these 3 functions

 - it's confusing -- at first sight, it seems like **kwargs will be taken in to be used by a subclass or maybe stored as attrs on the instance and not used, and it seems like arbitrary kwargs can be given.

 - the only reason it was done so, I guess, is that the list is long and unwieldy. But that's also the reason why the listing under TextWrap takes up more than a screenful and so more of an argument to have a compact list in the signature.

 - in case of fill, some args are a no-op, so they can be omitted from the signature, that will make it much easier to see all effective arguments.

----------
assignee: docs at python
components: Documentation
messages: 396817
nosy: andrei.avk, docs at python
priority: normal
severity: normal
status: open
title: Add full list of possible args to textwrap: wrap, fill, shorten
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Jul  1 14:30:28 2021
From: report at bugs.python.org (skoolbeep)
Date: Thu, 01 Jul 2021 18:30:28 +0000
Subject: [New-bugs-announce] [issue44545] ASSESSMENT TOOLS
Message-ID: <1625164228.87.0.934989407093.issue44545@roundup.psfhosted.org>


New submission from skoolbeep <skoolbeepseo at gmail.com>:

Online assessment tools are a necessary part of remote learning education. If the teachers and professors have a firm hold on a student?s learning graph, he can do wonders in life!

----------
messages: 396822
nosy: skoolbeep
priority: normal
severity: normal
status: open
title: ASSESSMENT TOOLS

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

From report at bugs.python.org  Thu Jul  1 14:45:50 2021
From: report at bugs.python.org (skoolbeep)
Date: Thu, 01 Jul 2021 18:45:50 +0000
Subject: [New-bugs-announce] [issue44546] ASSESSMENT TOOLS
Message-ID: <1625165150.78.0.86979593254.issue44546@roundup.psfhosted.org>


New submission from skoolbeep <skoolbeepseo at gmail.com>:

We all are familiar with the age-old algorithm where people emphasize on grades. Grades matter, but so does an understanding of the topic. Online assessment tools are a necessary part of remote learning education. If the teachers and professors have a firm hold on a student?s learning graph, he can do wonders in life!
https://www.skoolbeep.com/blog/conduct-online-assessments-effectively/

----------
messages: 396825
nosy: skoolbeep
priority: normal
severity: normal
status: open
title: ASSESSMENT TOOLS

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

From report at bugs.python.org  Thu Jul  1 15:52:28 2021
From: report at bugs.python.org (Michael Amrhein)
Date: Thu, 01 Jul 2021 19:52:28 +0000
Subject: [New-bugs-announce] [issue44547] fraction.Fraction does not
 implement __int__.
Message-ID: <1625169148.48.0.541804995208.issue44547@roundup.psfhosted.org>


New submission from Michael Amrhein <michael at adrhinum.de>:

While int, float, complex and Decimal implement __int__, Fraction does not. Thus, checking for typing.SupportsInt for fractions fails, although int(<fraction>) succeeds, because Fraction implements __trunc__.
This looks inconsistent.
Easiest fix seems to be: Fraction.__int__ = Fraction.__trunc__

----------
components: Library (Lib)
messages: 396827
nosy: mamrhein
priority: normal
severity: normal
status: open
title: fraction.Fraction does not implement __int__.
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jul  1 16:15:05 2021
From: report at bugs.python.org (Phil Soucheray)
Date: Thu, 01 Jul 2021 20:15:05 +0000
Subject: [New-bugs-announce] [issue44548] ttk Indeterminate Progressbar Not
 Animating Correctly After `start`
Message-ID: <1625170505.27.0.877381236302.issue44548@roundup.psfhosted.org>


New submission from Phil Soucheray <souch32 at me.com>:

After running `start` on an indeterminate Progressbar, it animates to one side, goes back to the other and then right before it reaches the end it disappears. I've attached a sample script below and a screen recording. This is running on macOS 11.3 and python 3.9.6 with the tkinter version that is packaged with the 3.9.6 installer. 


```
from tkinter import *
from tkinter.ttk import *
import time

window = Tk()
window.title('Test')
window.geometry('400x250+1000+300')


pb = Progressbar(window, orient=HORIZONTAL, length=100, mode='indeterminate')
pb.pack(expand=True)

Button(window, text='Start', command=pb.start).pack()

window.mainloop()
```

----------
components: Tkinter
files: Screen Recording 2021-07-01 at 1.11.26 PM.mov
messages: 396828
nosy: souch3
priority: normal
severity: normal
status: open
title: ttk Indeterminate Progressbar Not Animating Correctly After `start`
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50137/Screen Recording 2021-07-01 at 1.11.26 PM.mov

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

From report at bugs.python.org  Fri Jul  2 06:46:07 2021
From: report at bugs.python.org (siddhartha shankar mahato)
Date: Fri, 02 Jul 2021 10:46:07 +0000
Subject: [New-bugs-announce] [issue44549] BZip 1.0.6 Critical Vulnerability
Message-ID: <1625222767.58.0.244231438459.issue44549@roundup.psfhosted.org>


New submission from siddhartha shankar mahato <s.s.mahato at gmail.com>:

Python (3.9.5 and 3.9.6 are using Bzip2 1.0.6 which has a known critical vulnerability. 
CVE-2019-12900 (BDSA-2019-1844)
9.8 Critical NVD CVE-2016-3189 (BDSA-2019-2036).

Please upgrade the same to a stable version.

----------
components: Windows
messages: 396853
nosy: paul.moore, s.s.mahato, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: BZip 1.0.6 Critical Vulnerability
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul  2 07:03:54 2021
From: report at bugs.python.org (skoolbeep)
Date: Fri, 02 Jul 2021 11:03:54 +0000
Subject: [New-bugs-announce] [issue44550] DIGITAL CLASSROOM
Message-ID: <1625223834.82.0.0485428221389.issue44550@roundup.psfhosted.org>


New submission from skoolbeep <skoolbeepseo at gmail.com>:

A digital classroom setup can be defined as a learning environment created with the help of electronic devices that run on software programmes. 
https://www.skoolbeep.com/blog/what-makes-up-a-good-digital-classroom/

----------
messages: 396854
nosy: skoolbeep
priority: normal
severity: normal
status: open
title: DIGITAL CLASSROOM

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

From report at bugs.python.org  Fri Jul  2 08:52:25 2021
From: report at bugs.python.org (user_0101)
Date: Fri, 02 Jul 2021 12:52:25 +0000
Subject: [New-bugs-announce] [issue44551] Substraction: unprecise result
Message-ID: <1625230345.07.0.72241721033.issue44551@roundup.psfhosted.org>


New submission from user_0101 <mmir at seznam.cz>:

```
>>> 2.11-1.56
0.5499999999999998
```

----------
messages: 396862
nosy: user_0101
priority: normal
severity: normal
status: open
title: Substraction: unprecise result
versions: Python 3.8

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

From report at bugs.python.org  Fri Jul  2 10:08:59 2021
From: report at bugs.python.org (Erik Carstensen)
Date: Fri, 02 Jul 2021 14:08:59 +0000
Subject: [New-bugs-announce] [issue44552] incomplete documentation of
 __main__.py
Message-ID: <1625234939.05.0.135731046929.issue44552@roundup.psfhosted.org>


New submission from Erik Carstensen <mandolaerik at gmail.com>:

I can find partial information on how Python treats __main__.py here: https://docs.python.org/3/library/__main__.html

However, it is not documented how python handles __main__.py when passing the Python package to the interpreter without -m. If I have a program defined by /tmp/foo/bar.py and a file /tmp/foo/__main__.py, and I run

python /tmp/foo

... then Python will run __main__.py, with /tmp/foo prepended to sys.path.

I find this behaviour unfortunate; to me it would make more sense to prepend /tmp to sys.path, because then "python /tmp/foo" would be equivalent to "PYTHONPATH=/tmp python -m foo". With the current behaviour, if __main__.py wants to import bar.py, then it must write 'import bar' or 'import foo.bar' depending on whether the interpreter was invoked with -m.

Unfortunately, by Hyrum's Law, you can find people describing and encouraging reliance upon the current undocumented behaviour, e.g.:
https://www.geeksforgeeks.org/usage-of-__main__-py-in-python/
so perhaps the behaviour can't be changed that easily. Therefore, my request is to document how it works.

----------
assignee: docs at python
components: Documentation
messages: 396865
nosy: docs at python, mandolaerik
priority: normal
severity: normal
status: open
title: incomplete documentation of __main__.py
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Jul  2 10:53:38 2021
From: report at bugs.python.org (Ken Jin)
Date: Fri, 02 Jul 2021 14:53:38 +0000
Subject: [New-bugs-announce] [issue44553] types.Union should support GC
Message-ID: <1625237618.48.0.776218166977.issue44553@roundup.psfhosted.org>


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

types.Union objects can contain reference cycles, therefore causing memory leaks.

E.g.::

```
import sys, gc
from typing import TypeVar

gc.collect()
for _ in range(10):
 sys.gettotalrefcount()
 T = TypeVar('T')
 U = int | list[T]
 T.blah = U
 del T
 del U
 gc.collect()
```
Result:
84470
0
84488
0
84504
0
84520
0
84536
0

I'm sending a small PR soon to implement GC methods to fix this.

----------
messages: 396867
nosy: gvanrossum, kj
priority: normal
severity: normal
status: open
title: types.Union should support GC
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jul  2 16:47:02 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 02 Jul 2021 20:47:02 +0000
Subject: [New-bugs-announce] [issue44554] pdb.main is unnecessarily
 complicated
Message-ID: <1625258822.01.0.642754622025.issue44554@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

While investigating issue44461, I observed some complexities to the current pdb.main implementation, some of which likely contributed to the bug being present.

- variables are initialized to defaults (https://github.com/python/cpython/blob/ec8759b060eff83ff466f42c5a96d83a685016ce/Lib/pdb.py#L1677-L1678) and then mutated (https://github.com/python/cpython/blob/ec8759b060eff83ff466f42c5a96d83a685016ce/Lib/pdb.py#L1684-L1686) based on other variables.

- mainpyfile is conditionally mutated based on previous values of conditionally mutated variables (https://github.com/python/cpython/blob/ec8759b060eff83ff466f42c5a96d83a685016ce/Lib/pdb.py#L1696).

- There are three different blocks of code (https://github.com/python/cpython/blob/ec8759b060eff83ff466f42c5a96d83a685016ce/Lib/pdb.py#L1690-L1691, https://github.com/python/cpython/blob/ec8759b060eff83ff466f42c5a96d83a685016ce/Lib/pdb.py#L1696-L1698, and https://github.com/python/cpython/blob/ec8759b060eff83ff466f42c5a96d83a685016ce/Lib/pdb.py#L1711) that are conditionally run based on run_as_module.

These factors mean that all of these lines of code are entangled in ways that are somewhat difficult to reason about. For example, it's unclear what states have been achieved by the time `pdb._run*` is constructed, or what exceptions may or may not be expected for these calls.

A functional or OO approach would limit the amount of mutation and entanglement (through encapsulation or scoping).

An OO approach would have a protocol or interface that captures the different behaviors required prior to and on invocation of `Pdb._run*`.

For example, the PDB "targets" (script or module) could be modeled as separate classes and provide symmetric interfaces with (possibly degenerate) equivalent operations for each use-case.

To be sure, the code that's present is adequate and in my opinion right on the border of benefiting from a more rigorous abstraction. The current imperative approach is fairly readable and mostly comprehensible. It's only because of the surprise behavior in the reported issue that I propose to step back and contemplate ways to alleviate the concerns above.

----------
components: Library (Lib)
messages: 396877
nosy: iritkatriel, jaraco
priority: normal
severity: normal
status: open
title: pdb.main is unnecessarily complicated
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul  2 17:20:05 2021
From: report at bugs.python.org (Daniel Fleischman)
Date: Fri, 02 Jul 2021 21:20:05 +0000
Subject: [New-bugs-announce] [issue44555] Dictionary operations are LINEAR
 for any dictionary (for a particular code).
Message-ID: <1625260805.66.0.276677787227.issue44555@roundup.psfhosted.org>


New submission from Daniel Fleischman <danielfleischman at gmail.com>:

The following code takes quadratic time on the size of the dictionary passed, regardless of the dictionary (explanation below):

```
def slow_dictionary(d):
    while len(d) > 0:
        # Remove first element
        key = next(iter(d))
        del d[key]
```

The problem is that when an element is deleted a NULL/NULL placeholder is set in its place (https://github.com/python/cpython/blob/818628c2da99ba0376313971816d472c65c9a9fc/Objects/dictobject.c#L1534) and when we try to find the first element with `next(iter(d))` the code needs to skip over all the NULL elements until it finds the first non-NULL element (https://github.com/python/cpython/blob/818628c2da99ba0376313971816d472c65c9a9fc/Objects/dictobject.c#L1713).

I'm not sure of what is the best way to fix it, but note that simply adding a field to the struct with the position of the first non-NULL element is not enough, since a code that always deletes the SECOND element of the dictionary would still have linear operations.

An easy (but memory-wasteful) fix would be to augment the struct PyDictKeyEntry with the indices of the next/previous non empty elements, and augment _dictkeysobject with the index of the first and last non empty elements (in other words, maintain an underlying linked list of the non empty entries). With this we can always iterate in O(1) per entry.

(I tested it only on version 3.9.2, but I would be surprised if it doesn't happen in other versions as well).

----------
components: Interpreter Core
messages: 396880
nosy: danielfleischman
priority: normal
severity: normal
status: open
title: Dictionary operations are LINEAR for any dictionary (for a particular code).
type: performance
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jul  2 21:27:44 2021
From: report at bugs.python.org (Zan)
Date: Sat, 03 Jul 2021 01:27:44 +0000
Subject: [New-bugs-announce] [issue44556] ctypes unittest crashes with
 libffi 3.4.2
Message-ID: <1625275664.18.0.784580950779.issue44556@roundup.psfhosted.org>


New submission from Zan <zan at lavabit.com>:

Running the unittests after upgrading libffi to latest version 3.4.2 and recompiling python, leads to several tests in Lib/ctypes/test/ to crash with Abort: trap 6. This does not happen with version 3.3 of libffi.

Steps to reproduce:

git clone https://github.com/libffi/libffi
cd libffi
autoreconf -fvi
export CC=/usr/bin/clang
./configure
make
sudo make install # installs into /usr/local

git clone https://github.com/python/CPython
cd CPython
export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
export CPPFLAGS="-I/usr/local/include" 
export LDFLAGS="-L/usr/local/lib"
./configure --with-system-ffi
make
./python Lib/ctypes/test/__main__.py -v

...
test_callbacks (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... Abort trap: 6

If I repeat the above steps with 'git checkout v3.3' in libffi, all tests in ctypes complete successfully.

Tested with :
- python 3.11 commit ec8759b0 (current master), also tried 3.8.11
- libffi 3.4.2
- macOS 11.4, Xcode 12.5.1
- MacBook Air, x86_64, Intel Sky Lake, i5-8210Y

----------
components: ctypes
messages: 396885
nosy: zan
priority: normal
severity: normal
status: open
title: ctypes unittest crashes with libffi 3.4.2
type: crash
versions: Python 3.11, Python 3.8

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

From report at bugs.python.org  Sat Jul  3 09:29:26 2021
From: report at bugs.python.org (Matheus Oliveira)
Date: Sat, 03 Jul 2021 13:29:26 +0000
Subject: [New-bugs-announce] [issue44557] It's a bug? Dict
Message-ID: <1625318966.36.0.655841423385.issue44557@roundup.psfhosted.org>


New submission from Matheus Oliveira <ymatheus63 at gmail.com>:

a = {"a":1}

b = a

a["a"]=33

print(b, a)

# {"a":33}, {"a":33}

----------
components: Interpreter Core
messages: 396899
nosy: ymatheus63
priority: normal
severity: normal
status: open
title: It's a bug? Dict
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Sat Jul  3 13:25:15 2021
From: report at bugs.python.org (Rupert Tombs)
Date: Sat, 03 Jul 2021 17:25:15 +0000
Subject: [New-bugs-announce] [issue44558] operator.countOf `is` / `==`
 inconsistency
Message-ID: <1625333115.02.0.937139406208.issue44558@roundup.psfhosted.org>


New submission from Rupert Tombs <rupert.tombs at gmail.com>:

operator.countOf behaves differently in its docstring and its c and python implementations when `is` and `==` differ.

help(countOf) ->

    countOf(a, b, /)
        Return the number of times b occurs in a.

This could be read to say that it returns equal to `sum(x is b for x in a)`.

Its python implementation returns `sum(x == b for x in a)`.

Since its c implementation uses `PyObject_RichCompareBool`, it returns `sum(x is b or x == b for x in a)`.

Results of these implementations can differ when `x is b` does not imply `x == b`;
that could be from an __eq__ method, but the the float NaN is a real example since NaN != NaN.


The issue is demonstrated with a possible fix here https://godbolt.org/z/cPT7TToG7


Since the c version has been in the wild for decades, I suggest that it should be taken to define the function;
the python should be updated to match it, and the docstring could say
"Return the number of items in a which are, or which equal, b."

I will open a pull request with these changes shortly.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 396917
nosy: docs at python, rtombs
priority: normal
severity: normal
status: open
title: operator.countOf `is` / `==` inconsistency
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jul  3 21:48:24 2021
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 04 Jul 2021 01:48:24 +0000
Subject: [New-bugs-announce] [issue44559] Enum: revert to 3.9
Message-ID: <1625363304.74.0.624005694289.issue44559@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

>From the SC (was Re: Enum -- last call for comments on 3.10 changes)
--------------------------------------------------------------------
> The Steering Council discussed this topic at our meeting yesterday.  We have some
> discomfort about the changes to Enum?s str and repr in Python 3.10, both in the
> specific changes and in the way the changes were decided on.  No knock on Ethan or
> others who participated in those decisions, it?s just that to us, the changes
> cumulatively feel like they need a more formal, centralized discussion to understand
> all the issues in detail.
> 
> While we?re stopping short of requiring it, the Steering Council strongly suggests that
> for Python 3.10, the changes in Enum?s str and repr be reverted back to the Python 3.9
> behavior, and that a PEP be written for Python 3.11.

The changes were primarily spurred both by the changes to re.RegexFlag and by unfortunate choices made in enum.Flag regarding aliases and iteration that were corrected.

Unfortunately, it proved too difficult to revert the Flag repr() while keeping the corrections, so the entire enum module is being reverted to its 3.9 version.

All the bug-fixes, performance improvements, and other enhancements will have to wait for 3.11.

----------
assignee: ethan.furman
components: Library (Lib)
messages: 396935
nosy: barry, brett.cannon, ethan.furman, pablogsal, twouters, willingc
priority: release blocker
severity: normal
status: open
title: Enum: revert to 3.9
versions: Python 3.10

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

From report at bugs.python.org  Sun Jul  4 04:32:11 2021
From: report at bugs.python.org (TommyLike Hu)
Date: Sun, 04 Jul 2021 08:32:11 +0000
Subject: [New-bugs-announce] [issue44560] Unrecognized charset
 "eucgb2312_cn" in email header for many MUA
Message-ID: <1625387531.16.0.849810673355.issue44560@roundup.psfhosted.org>


New submission from TommyLike Hu <tommylikehu at gmail.com>:

Email module is used for email message decode and encode, if the header content is gb2312 encoded for example "??", by design we would finally have a rfc-2047 encoded header as below:
```
=?eucgb2312_cn?b?1tDOxA==?=
```
the test script is as below:
```
from email import header, charset

h = header.make_header([(str("??").encode("gb2312"),
                         charset.Charset("gb2312"))])
print(h.encode())
```

My question is why don't we use "gb2312" as the charset in rfc-2047 encoded string, considering the "eucgb2312_cn" is only python awareness.

Thanks

----------
components: email
messages: 396939
nosy: barry, r.david.murray, tommylikehu
priority: normal
severity: normal
status: open
title: Unrecognized charset "eucgb2312_cn" in email header for many MUA
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Jul  4 09:33:38 2021
From: report at bugs.python.org (Steven Hsu)
Date: Sun, 04 Jul 2021 13:33:38 +0000
Subject: [New-bugs-announce] [issue44561] Some expired hyperlinks in Python
 documentation
Message-ID: <1625405618.41.0.0286590833037.issue44561@roundup.psfhosted.org>


New submission from Steven Hsu <hsuhaochun at gmail.com>:

In https://github.com/python/cpython/blob/main/Doc/distributing/index.rst, there are three expired hyperlinks:

.. _Project structure: \
    https://packaging.python.org/tutorials/distributing-packages/
.. _Building and packaging the project: \
   https://packaging.python.org/tutorials/distributing-packages/#packaging-your-project
.. _Uploading the project to the Python Packaging Index: \
   https://packaging.python.org/tutorials/distributing-packages/#uploading-your-project-to-pypi

And it should be fixed in this way:

.. _Project structure: \
    https://packaging.python.org/tutorials/packaging-projects/#packaging-python-projects
.. _Building and packaging the project: \
   https://packaging.python.org/tutorials/packaging-projects/#creating-the-package-files
.. _Uploading the project to the Python Packaging Index: \
   https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives

Thanks.

----------
assignee: docs at python
components: Documentation
files: index.rst
messages: 396941
nosy: StevenHsuYL, docs at python
priority: normal
severity: normal
status: open
title: Some expired hyperlinks in Python documentation
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file50139/index.rst

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

From report at bugs.python.org  Sun Jul  4 11:34:00 2021
From: report at bugs.python.org (Ken Jin)
Date: Sun, 04 Jul 2021 15:34:00 +0000
Subject: [New-bugs-announce] [issue44562] types.GenericAlias should decref
 instead of using delete in tp_new
Message-ID: <1625412840.28.0.957157169127.issue44562@roundup.psfhosted.org>


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

Ref: comment chain at https://github.com/python/cpython/pull/27008#discussion_r663450441.

setup_ga fails only if PyTuple_Pack fails, which usually happens when Python is out of memory. The cleanup code for setup_ga shouldn't use PyObject_GC_DEL as mentioned in Pablo's comment above.

I don't know how to add a test for out of memory, so I'll send a PR without test soon.

----------
messages: 396944
nosy: kj, pablogsal
priority: normal
severity: normal
status: open
title: types.GenericAlias should decref instead of using delete in tp_new
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Jul  4 14:11:14 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Jul 2021 18:11:14 +0000
Subject: [New-bugs-announce] [issue44563] Failed tee.fromiterable() corrupts
 the linked list of all GC objects in debug build
Message-ID: <1625422274.31.0.182880116213.issue44563@roundup.psfhosted.org>


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

In tee.fromiterable() the non-initialized tee object can be deleted by  without calling _Py_ForgetReference() in debug build.

See also issue44553 and issue44562.

The proposed PR rewrites the code so that it no longer need to delete not completely initialized tee object.

----------
components: Extension Modules
messages: 396952
nosy: kj, pablogsal, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Failed tee.fromiterable() corrupts the linked list of all GC objects in debug build
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Jul  5 00:24:06 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 05 Jul 2021 04:24:06 +0000
Subject: [New-bugs-announce] [issue44564] DeprecationWarning in test_enum
 over formatting
Message-ID: <1625459046.43.0.477755678755.issue44564@roundup.psfhosted.org>


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

It seems the line above this is wrapped under a block to check for deprecation warning but this line got missed out.

PYTHONWARNINGS=always ./python.exe -Wall -m test test_enum
0:00:00 load avg: 3.91 Run tests sequentially
0:00:00 load avg: 3.91 [1/1] test_enum
/Users/kasingar/stuff/python/cpython/Lib/test/test_enum.py:2324: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an integer-based Enum, to maintain the current display
  self.assertEqual(OkayEnum.one, '{}'.format(OkayEnum.one))

== Tests result: SUCCESS ==

1 test OK.

Total duration: 257 ms
Tests result: SUCCESS

----------
components: Library (Lib)
keywords: newcomer friendly
messages: 396967
nosy: ethan.furman, xtreak
priority: normal
severity: normal
status: open
title: DeprecationWarning in test_enum over formatting
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Jul  5 05:09:06 2021
From: report at bugs.python.org (kevinshi)
Date: Mon, 05 Jul 2021 09:09:06 +0000
Subject: [New-bugs-announce] [issue44565] python configure config.status:
 error: cannot find input file: `config.sh.in'
Message-ID: <1625476146.85.0.858438616021.issue44565@roundup.psfhosted.org>


New submission from kevinshi <ssfxx1 at 163.com>:

config.status: error: cannot find input file: `config.sh.in'

----------
components: Installation
messages: 396977
nosy: kevinshi
priority: normal
severity: normal
status: open
title: python configure config.status: error: cannot find input file: `config.sh.in'
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Mon Jul  5 05:45:40 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Mon, 05 Jul 2021 09:45:40 +0000
Subject: [New-bugs-announce] [issue44566] StopIteration subclass raised in
 body of 'with' statement suppressed
Message-ID: <1625478340.34.0.529262409181.issue44566@roundup.psfhosted.org>


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

https://bugs.python.org/issue1462485


import contextlib

@contextlib.contextmanager
def foo():
    yield

class StartIrritation(StopIteration):
    pass


with foo():
    raise StartIrritation

----------
messages: 396979
nosy: graingert, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: StopIteration subclass raised in body of 'with' statement suppressed
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul  5 11:51:01 2021
From: report at bugs.python.org (schwaerz)
Date: Mon, 05 Jul 2021 15:51:01 +0000
Subject: [New-bugs-announce] [issue44567] venv fails when called from within
 long path on Windows
Message-ID: <1625500261.64.0.225547269039.issue44567@roundup.psfhosted.org>


New submission from schwaerz <joerg.schwaerzler at infineon.com>:

When trying to create a venv from within a long path name in Windows 10 (long paths enabled in the registry), python crashes. Used python 3.9.6.

When reducing the path length by one character, it starts working.
When disabling the long path support in Windows, I get an error message about paths being too long.

btw.: I can see same / similar behavior when using virtualenv/pipenv/poetry (did not try any other venv-like tooling...)

For the instructions please check the following snippet:

d:\slave\workspace\1--folder-with-232-character-absolute-path-length----------------------------------------------------------------------------------------------------------------------------------------------------------------232>python -m venv .venv
Error: Command '['d:\\slave\\workspace\\1--folder-with-232-character-absolute-path-length----------------------------------------------------------------------------------------------------------------------------------------------------------------232\\.venv\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 3221226505.

%Errorlevel% sometimes was 1 and sometimes was -1073740791 (0xc0000409). Unfortunately I cannot recalled what I had to do to get the latter one... I tried with python 3.8.0, too. Same behavior.

----------
components: Windows
messages: 397000
nosy: paul.moore, schwaerz, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: venv fails when called from within long path on Windows
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul  5 12:38:06 2021
From: report at bugs.python.org (tongxiaoge)
Date: Mon, 05 Jul 2021 16:38:06 +0000
Subject: [New-bugs-announce] [issue44568] test_constructor
 (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault
Message-ID: <1625503086.3.0.822137637944.issue44568@roundup.psfhosted.org>


New submission from tongxiaoge <shixuantong at huawei.com>:

I have reproduced this problem in the latest versions of Python 3.8.10 and 3.9.6. Python 3.8.5 does not have this problem, other versions are not tested. The failure log is as follows?
[  457s] 0:02:34 load avg: 9.29 Re-running test_ssl in verbose mode
[  457s] test_ssl: testing with 'OpenSSL 1.1.1f  31 Mar 2020' (1, 1, 1, 6, 15)
[  457s]           under 'Linux-4.19.36-vhulk1907.1.0.h748.eulerosv2r8.aarch64-aarch64-with-glibc2.17'
[  457s]           HAS_SNI = True
[  457s]           OP_ALL = 0x80000054
[  457s]           OP_NO_TLSv1_1 = 0x10000000
[  457s] test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
[  457s] test_cert_store_stats (test.test_ssl.ContextTests) ... ok
[  457s] test_check_hostname (test.test_ssl.ContextTests) ... ok
[  457s] test_ciphers (test.test_ssl.ContextTests) ... ok
[  457s] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault
[  457s] 
[  457s] Current thread 0x0000ffff8e225010 (most recent call first):
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/ssl.py", line 483 in __new__
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/test_ssl.py", line 1126 in test_constructor
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 650 in _callTestMethod
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 693 in run
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 753 in __call__
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 122 in run
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 84 in __call__
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 122 in run
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 84 in __call__
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/runner.py", line 176 in run
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/support/__init__.py", line 2030 in _run_suite
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/support/__init__.py", line 2152 in run_unittest
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/test_ssl.py", line 4848 in test_main
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 153 in _runtest
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 193 in runtest
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 694 in _main
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 637 in main
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 715 in main
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/regrtest.py", line 46 in _main
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/regrtest.py", line 50 in <module>
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/runpy.py", line 87 in _run_code
[  457s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/runpy.py", line 194 in _run_module_as_main
[  457s] /var/tmp/rpm-tmp.gGVNgB: line 50: 2329201 Segmentation fault      (core dumped) WITHIN_PYTHON_RPM_BUILD= LD_LIBRARY_PATH=$(pwd)/build/debug $(pwd)/build/debug/python -m test.regrtest -wW --slowest -j0 -x test_distutils -x test_bdist_rpm -x test_gdb -x test_socket -x test_asyncio
[  457s] error: Bad exit status from /var/tmp/rpm-tmp.gGVNgB (%check)

----------
components: Tests
messages: 397008
nosy: sxt1001
priority: normal
severity: normal
status: open
title: test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul  5 12:47:05 2021
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 05 Jul 2021 16:47:05 +0000
Subject: [New-bugs-announce] [issue44569] traceback.py: Allow customization
 of per-frame line formatting in StackSummary
Message-ID: <1625503625.05.0.62837078116.issue44569@roundup.psfhosted.org>


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

During the implementation of PEP 657, Terry Jan Reedy pointed out that in the format method of traceback.StackSummary there are two roles being fulfilled, there is some logic to handle omitting repeated lines involved in recursive calls and then the core per-frame formatting logic:
 https://github.com/python/cpython/blob/17f94e28882e1e2b331ace93f42e8615383dee59/Lib/traceback.py#L484-L503

To allow the per-line formatting to be overridden easily, these lines should be split into a separate method.

----------
assignee: ammar2
components: Library (Lib)
messages: 397009
nosy: BTaskaya, ammar2, pablogsal, terry.reedy
priority: normal
severity: normal
status: open
title: traceback.py: Allow customization of per-frame line formatting in StackSummary
versions: Python 3.11

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

From report at bugs.python.org  Mon Jul  5 18:29:38 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 05 Jul 2021 22:29:38 +0000
Subject: [New-bugs-announce] [issue44570] 3.10.0b3 doesn't trace line events
 for return in some cases
Message-ID: <1625524178.46.0.642583594704.issue44570@roundup.psfhosted.org>


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

(from https://github.com/nedbat/coveragepy/issues/1184)

This code runs the return statement on line 17 twice.  The second time, there is a "line" event and then a "return" event for that line.  But the first time, there is only a "return" event:

--- 8< -------------------------------
import linecache, sys

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

def foo(x):
    if x:
        try:
            1/(x - 1)
        except ZeroDivisionError:
            pass

    return x

def test_foo():
    for i in range(2):
        foo(i)

print(sys.version)
sys.settrace(trace)
test_foo()
-----------------------------------------

I get this output with 3.10.0b3:

3.10.0b3 (default, Jun 18 2021, 06:43:38) [Clang 12.0.0 (clang-1200.0.32.29)]
call 19: def test_foo():
line 20:     for i in range(2):
line 21:         foo(i)
call 10: def foo(x):
line 11:     if x:
retu 17:     return x
line 20:     for i in range(2):
line 21:         foo(i)
call 10: def foo(x):
line 11:     if x:
line 12:         try:
line 13:             1/(x - 1)
exce 13:             1/(x - 1)
line 14:         except ZeroDivisionError:
line 15:             pass
line 17:     return x
retu 17:     return x
line 20:     for i in range(2):
retu 20:     for i in range(2):


Shouldn't there be a "line" event for both invocations?

----------
components: Interpreter Core
keywords: 3.10regression
messages: 397024
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.10.0b3 doesn't trace line events for return in some cases
versions: Python 3.10

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

From report at bugs.python.org  Mon Jul  5 18:33:28 2021
From: report at bugs.python.org (pavel-lexyr)
Date: Mon, 05 Jul 2021 22:33:28 +0000
Subject: [New-bugs-announce] [issue44571] itertools: takedowhile()
Message-ID: <1625524408.64.0.445781965255.issue44571@roundup.psfhosted.org>


New submission from pavel-lexyr <pavel at lexyr.com>:

As described in the documentation, itertools.takewhile() returns all the elements until the first one that does not match the provided criterion. In case of a destructive iterator, or one with side effects, not yielding an element downstream may render takewhile() unsuitable for use.

Proposed is itertools.takedowhile() - an alternate function that yields the first false element as well, and returns after. The behaviour is identical otherwise.

----------
messages: 397025
nosy: pavel-lexyr, rhettinger
priority: normal
severity: normal
status: open
title: itertools: takedowhile()
type: enhancement

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

From report at bugs.python.org  Tue Jul  6 12:21:17 2021
From: report at bugs.python.org (=?utf-8?b?0JrQvtC90YHRgtCw0L3RgtC40L0g0JPQu9GD0YXQvtCy?=)
Date: Tue, 06 Jul 2021 16:21:17 +0000
Subject: [New-bugs-announce] [issue44572] Calls to platform._syscmd_ver()
 dependent functions consume STDIN
Message-ID: <1625588477.49.0.966107030836.issue44572@roundup.psfhosted.org>


New submission from ?????????? ?????? <glukhov.k at gmail.com>:

Starting with version 3.9.5 platform.win32* functions have been re-written and consume STDIN. The bug comes down to running 'ver', 'command /c ver', 'cmd /c ver' in platform._syscmd_ver() via subprocess.check_output().

The following code demonstrate the problem:

Python\396\python -c "import platform as p, sys;print(sys.stdin.tell());p.win32_ver();print(sys.stdin.tell())" < file
0
8000

All functions dependent on platform._syscmd_ver(), including platform.uname(), consume STDIN.

This behavior breaks all the scripts on Windows platform that have the calls mentioned above and use the following invocation:

python script.py < file

----------
components: IO, Library (Lib), Windows
messages: 397044
nosy: glukhov.k, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Calls to platform._syscmd_ver() dependent functions consume STDIN
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul  6 17:23:51 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Tue, 06 Jul 2021 21:23:51 +0000
Subject: [New-bugs-announce] [issue44573] Organize some data files in the
 Lib/test directory
Message-ID: <1625606631.33.0.288717184507.issue44573@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

I noticed that some data files (used to perform some specific tests) are not organized in specific directories of their categories. Some files that I found are audiotest.au, badcert.pem, badkey.pem, cfgparser.1, cfgparser.2, etc (some are even .py files).

I'm working on an organization so they don't get mixed up with the test files, but how the rest of the data files are organized (audiodata, capath, cjkencodings, etc.).

----------
components: Tests
messages: 397056
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Organize some data files in the Lib/test directory
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul  6 23:01:23 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 07 Jul 2021 03:01:23 +0000
Subject: [New-bugs-announce] [issue44574] IDLE: Implement or delete
 python-context-help.
Message-ID: <1625626883.0.0.841982901959.issue44574@roundup.psfhosted.org>


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

The config.IdleConf.GetCoreKeys keyBindings dict contains
   '<<python-context-help>>': ['<Shift-F1>']
The was included in the initial version by Steven Gava, 9930061c, on 2001 Dec 2.  So it appears in the Keys page of the config dialog, as noticed by Mondher on SO ((https://stackoverflow.com/questions/68263769/idle-shell-context-documentation-broken)

The string does not appear elsewhere in idlelib, nor is the feature mentioned in the IDLE doc.  So it is unimplemented and undocumented.  Based on experience with other IDEs (Mathematica) Mondher suggests that one should be able to select a word and have it looked up in the index of the document opened by python-doc F1.  'Very useful' he says.

On Windows, F1 opens an offline Windows help window with the Python docs.  Currently, modifier(s)-F1 is interpreted as F1 and the help window is opened.  I presume a shift-F1 binding will override that. I also presume that an argument can be added to the Windows open-help command.

I don't know about online docs on other systems and don't think we can access indexes on opened python webpages.  Where shift-F1 does not work, a message should be displayed.

If we decided to not implement index search anywhere, the line in config.py should be removed.

----------
assignee: terry.reedy
components: IDLE
messages: 397058
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Implement or delete python-context-help.
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul  7 00:36:02 2021
From: report at bugs.python.org (=?utf-8?b?0JrQvtC90YHRgtCw0L3RgtC40L0g0JPQu9GD0YXQvtCy?=)
Date: Wed, 07 Jul 2021 04:36:02 +0000
Subject: [New-bugs-announce] [issue44575] Windows installer prohibits
 different patches for the same version
Message-ID: <1625632562.86.0.44439048835.issue44575@roundup.psfhosted.org>


New submission from ?????????? ?????? <glukhov.k at gmail.com>:

Windows installer prohibits different patches for the same version.
I do not see any reason why the installer cannot put two different versions, e.g. 3.9.4 and 3.9.6 into different folders.
This makes it very difficult to debug issues introduced in higher versions. Please allow installation of different patches into separate folders.

----------
components: Installation, Windows
messages: 397063
nosy: glukhov.k, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer prohibits different patches for the same version
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul  7 05:23:56 2021
From: report at bugs.python.org (Andre Roberge)
Date: Wed, 07 Jul 2021 09:23:56 +0000
Subject: [New-bugs-announce] [issue44576] AttributeError: incorrect line
 identified in Python 3.10
Message-ID: <1625649836.78.0.756397616199.issue44576@roundup.psfhosted.org>


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

Consider the following program

# example.py
one = 1
two = "two"
a = [one
    .
    two]

Running this program with Python versions before 3.10, yields the following traceback:

Traceback (most recent call last):
  File "C:\Users\andre\example.py", line 3, in <module>
    a = [one
AttributeError: 'int' object has no attribute 'two'

The line shown correctly includes the 'int' object. I have verified that this is the case for Python 3.6 to 3.9 inclusively.

However, with Python version 3.10.0b3, the following traceback is generated:

Traceback (most recent call last):
  File "C:\Users\andre\example.py", line 5, in <module>
    two]
AttributeError: 'int' object has no attribute 'two'

----------
messages: 397067
nosy: aroberge
priority: normal
severity: normal
status: open
title: AttributeError: incorrect line identified in Python 3.10
versions: Python 3.10

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

From report at bugs.python.org  Wed Jul  7 06:15:20 2021
From: report at bugs.python.org (Vladislav Kozlenko)
Date: Wed, 07 Jul 2021 10:15:20 +0000
Subject: [New-bugs-announce] [issue44577] Probably defect in Python 3.7.11
Message-ID: <1625652920.8.0.16553812104.issue44577@roundup.psfhosted.org>


New submission from Vladislav Kozlenko <vladislavko at softwareplanet.uk.com>:

After upgrade to 3.7.11 from 3.7.10 WebSockets start failing.
Django==2.1.2
djangorestframework==3.8.2
daphne==2.3.0
channels==2.3.1

>From the 3.7.11 changelog:
Following the controlling specification for URLs defined by WHATWG urllib.parse() now removes ASCII newlines and tabs from URLs, preventing such attacks.

Probably something is not good here now.


2021-07-07T10:11:23.439030174Z2021-07-07 10:11:23,438 ERROR [Failure instance: Traceback: <class 'AttributeError'>: 'NoneType' object has no attribute 'replace'
Error
2021-07-07T10:11:23.439074685Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/autobahn/websocket/protocol.py:2841:processHandshake
Error
2021-07-07T10:11:23.439091149Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/txaio/tx.py:366:as_future
Error
2021-07-07T10:11:23.439097914Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/twisted/internet/defer.py:167:maybeDeferred
Error
2021-07-07T10:11:23.439118640Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/daphne/ws_protocol.py:82:onConnect
Error
2021-07-07T10:11:23.439122445Z--- <exception caught here> ---
Error
2021-07-07T10:11:23.439125845Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/twisted/internet/defer.py:167:maybeDeferred
Error
2021-07-07T10:11:23.439129088Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/daphne/server.py:200:create_application
Error
2021-07-07T10:11:23.439132308Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/channels/routing.py:58:__call__
Error
2021-07-07T10:11:23.439135496Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/channels/security/websocket.py:35:__call__
Error
2021-07-07T10:11:23.439138809Z/root/.local/share/virtualenvs/app-4PlAip0Q/lib/python3.7/site-packages/channels/security/websocket.py:53:valid_origin

----------
components: Library (Lib)
messages: 397069
nosy: vladislavko
priority: normal
severity: normal
status: open
title: Probably defect in Python 3.7.11
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Wed Jul  7 07:37:54 2021
From: report at bugs.python.org (Michael)
Date: Wed, 07 Jul 2021 11:37:54 +0000
Subject: [New-bugs-announce] [issue44578] dict with more than two type
 parameters doesn't raise a TypeError
Message-ID: <1625657874.87.0.018743781602.issue44578@roundup.psfhosted.org>


New submission from Michael <login at michaelthe.com>:

dict with three type parameters is legal (e.g., dict[str, str, str]), where I expected a TypeError. When using typing.Dict, it does raise a TypeError.

Example in python 3.9:

>>> from typing import Dict
>>> Dict[str, str, str]  # Raises a TypeError, as expected
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/michaelthe/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 275, in inner
    return func(*args, **kwds)
  File "/Users/michaelthe/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 828, in __getitem__
    _check_generic(self, params, self._nparams)
  File "/Users/michaelthe/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 212, in _check_generic
    raise TypeError(f"Too {'many' if alen > elen else 'few'} parameters for {cls};"
TypeError: Too many parameters for typing.Dict; actual 3, expected 2
>>> dict[str, str, str]  # No TypeError here?
dict[str, str, str]

This also works in 3.7 and 3.8:

Python 3.8.11 (default, Jul  6 2021, 12:13:09) 
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import annotations
>>> dict[str, str, str]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'type' object is not subscriptable
>>> def foo(bar: dict[str, str, str]): pass
... 
>>> foo.__annotations__
{'bar': 'dict[str, str, str]'}

----------
messages: 397073
nosy: mthe
priority: normal
severity: normal
status: open
title: dict with more than two type parameters doesn't raise a TypeError
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul  7 08:11:29 2021
From: report at bugs.python.org (sfmc)
Date: Wed, 07 Jul 2021 12:11:29 +0000
Subject: [New-bugs-announce] [issue44579] shutil.copy() inefficient
 implementation in Windows
Message-ID: <1625659889.31.0.269732165644.issue44579@roundup.psfhosted.org>


New submission from sfmc <Sergey_Filimonov at mentor.com>:

In Windows shutil.copy() uses _copyfileobj_readinto which copies file in user mode.
In Windows there is an fast API to copy file in kernel mode: CopyFile (see https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-copyfile).

----------
components: Library (Lib)
messages: 397076
nosy: sfmc
priority: normal
severity: normal
status: open
title: shutil.copy() inefficient implementation in Windows
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Wed Jul  7 09:28:25 2021
From: report at bugs.python.org (Hayden Clark)
Date: Wed, 07 Jul 2021 13:28:25 +0000
Subject: [New-bugs-announce] [issue44580] pprint does not work for
 typing.Mapping
Message-ID: <1625664505.94.0.691347848002.issue44580@roundup.psfhosted.org>


Change by Hayden Clark <pythonbugsmail at clarkccc.com>:


----------
components: Library (Lib)
nosy: hclark
priority: normal
severity: normal
status: open
title: pprint does not work for typing.Mapping
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Jul  7 10:31:57 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 07 Jul 2021 14:31:57 +0000
Subject: [New-bugs-announce] [issue44581] Interpreter can execute quickened
 opcodes in tracing mode
Message-ID: <1625668317.03.0.495409770321.issue44581@roundup.psfhosted.org>


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

This breaks a key invariant of PEP 659.

Inserting `assert(cframe.use_tracing == 0);` at the top of all quickened instructions results in several failures when running the test suite.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 397090
nosy: Mark.Shannon, kj
priority: normal
severity: normal
stage: needs patch
status: open
title: Interpreter can execute quickened opcodes in tracing mode
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul  7 16:06:39 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 07 Jul 2021 20:06:39 +0000
Subject: [New-bugs-announce] [issue44582] Accelerate mimetypes.init on
 Windows
Message-ID: <1625688399.61.0.349492251781.issue44582@roundup.psfhosted.org>


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

mimetypes.init is slow on Windows because of the big registry search, which involves touching thousands of entries in order to add a few hundred into the initial table.

Things get even worse when audit hooks are enabled, because the winreg methods need to be hooked. However, we know that this particular operation is coming from core, and so we could skip these hooks.

Both issues can be trivially solved (helped) with a native accelerator function.

----------
assignee: steve.dower
messages: 397110
nosy: steve.dower
priority: normal
severity: normal
status: open
title: Accelerate mimetypes.init on Windows
type: performance
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Jul  8 04:04:32 2021
From: report at bugs.python.org (Jay Krell)
Date: Thu, 08 Jul 2021 08:04:32 +0000
Subject: [New-bugs-announce] [issue44583] Failure to build on OSF1.
Message-ID: <1625731472.11.0.0989263409796.issue44583@roundup.psfhosted.org>


New submission from Jay Krell <jay.krell at cornell.edu>:

Python fails to compile on OSF1.
I have it about working. (I have Python2 already working.)
I'm opening an issue to meet the PR guidelines.

----------
components: Interpreter Core
messages: 397128
nosy: jaykrell
priority: normal
severity: normal
status: open
title: Failure to build on OSF1.
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul  8 05:23:09 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jul 2021 09:23:09 +0000
Subject: [New-bugs-announce] [issue44584] Deprecate thread debugging
 PYTHONTHREADDEBUG=1
Message-ID: <1625736189.01.0.129279218782.issue44584@roundup.psfhosted.org>


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

Copy of my email to python-dev:
https://mail.python.org/archives/list/python-dev at python.org/thread/NMLGCDRUKLZSTK4UICJTKR54WRXU2ZGJ/

Hi,

Does anyone use threading debug PYTHONTHREADDEBUG=1 env var on a
Python debug build? If not, can I just remove it?

--

To fix a race condition at thread exit on Linux using the glibc, I
removed calls to pthread_exit() (PyThread_exit_thread()) in the
_thread module:

   https://bugs.python.org/issue44434

A side effect of this change is the removal of the
"PyThread_exit_thread called" threading debug log when using
PYTHONTHREADDEBUG=1 environment variable.

I never used PYTHONTHREADDEBUG. I just tried it and it produces tons
of output in stdout about locks. It looks basically useless because it
produces way too many logs, and it pollutes stdout (ex: most Python
tests fail when it's enabled).

This debug mode requires to build Python in debug mode (./configure
--with-pydebug):

   https://docs.python.org/dev/using/configure.html#python-debug-build

IMO there are enough external debugging tools to debug threading
issues. Python no longer has to come with its built-in logs.

I propose to deprecate the feature in Python 3.11 and remove it in 2
releases (Python 3.13).

Victor

----------
components: Interpreter Core
messages: 397130
nosy: vstinner
priority: normal
severity: normal
status: open
title: Deprecate thread debugging PYTHONTHREADDEBUG=1
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul  8 09:13:28 2021
From: report at bugs.python.org (Marco E.)
Date: Thu, 08 Jul 2021 13:13:28 +0000
Subject: [New-bugs-announce] [issue44585] csv library does not correctly
 interpret some files
Message-ID: <1625750008.87.0.451821188518.issue44585@roundup.psfhosted.org>


New submission from Marco E. <marco.esposito at gmail.com>:

The CSV library does not correctly interpret files in the following format (test.csv):

"A"     ,"B"      ,"C"
"aaaaaa","bbbbbbb","cccc"
"aaaaa" ,"bbbbbb" ,"ccc"
"aaaa"  ,"bbbbb"  ,"cc"


This program:

import csv
from pathlib import Path


def main():
    with Path('test.csv').open('rt') as csv_file:
        csv.register_dialect('my_dialect', quotechar='"', delimiter=',',
                             quoting=csv.QUOTE_ALL, skipinitialspace=True)
        reader = csv.DictReader(csv_file, dialect='my_dialect')
        for row in reader:
            print(row)


if __name__ == '__main__':
    main()


produces the following output:

{'A     ': 'aaaaaa', 'B      ': 'bbbbbbb', 'C': 'cccc'}
{'A     ': 'aaaaa ', 'B      ': 'bbbbbb ', 'C': 'ccc'}
{'A     ': 'aaaa  ', 'B      ': 'bbbbb  ', 'C': 'cc'}


this instead is the expected result:

{'A': 'aaaaaa', 'B': 'bbbbbbb', 'C': 'cccc'}
{'A': 'aaaaa', 'B': 'bbbbbb', 'C': 'ccc'}
{'A': 'aaaa', 'B': 'bbbbb', 'C': 'cc'}


why?

Thank you,
Marco

----------
components: Library (Lib)
messages: 397139
nosy: voidloop
priority: normal
severity: normal
status: open
title: csv library does not correctly interpret some files
versions: Python 3.9

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

From report at bugs.python.org  Thu Jul  8 11:03:09 2021
From: report at bugs.python.org (ma19)
Date: Thu, 08 Jul 2021 15:03:09 +0000
Subject: [New-bugs-announce] [issue44586] unittest requires __init__.py for
 test discovery
Message-ID: <1625756589.94.0.0608514933284.issue44586@roundup.psfhosted.org>


New submission from ma19 <matthew.bolognani at broadcom.com>:

This is how my project is currently set up:

src:
  - main.py
  - src1.py
  - src2.py
test:
  - __init__.py
  - test_src1.py
  - test_src2.py

If I remove __init__.py from the "test" directory, the unittest discovery fails.

I thought that __init__.py was no longer required since Python 3.3. Will the test discovery be able to work without __init__.py in the future?

----------
components: Library (Lib)
messages: 397144
nosy: ma19
priority: normal
severity: normal
status: open
title: unittest requires __init__.py for test discovery
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul  9 01:07:37 2021
From: report at bugs.python.org (Toshio Kuratomi)
Date: Fri, 09 Jul 2021 05:07:37 +0000
Subject: [New-bugs-announce] [issue44587] BooleanOptionalAction displays
 default=SUPPRESS unlike other action types
Message-ID: <1625807257.47.0.987336531003.issue44587@roundup.psfhosted.org>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

This is related to https://bugs.python.org/issue38956 but a different symptom (and the current proposed fix for 38956 will not fix this.  My proposed fixes for this would also fix 38956).

I have the following code which uses BooleanOptionalAction along with a default of SUPPRESS (I use SUPPRESS because I merge these with settings from config and environment variables and then validate and add default values using a schema.  SUPPRESS allows me to tell when a value was not specified at the command line by the user):

    whole_site_parser.add_argument('--indexes',    
                                   dest='indexes', action=BooleanOptionalAction,    
                                   default=argparse.SUPPRESS,    
                                   help='Test')


That code outputs:

  --indexes, --no-indexes
                        Test (default: ==SUPPRESS==)

Similar code that does not use BooleanOptionalAction does not show default: ==SUPPRESS == even when formatter_class=ArgumentDefaultsHelpFormatter is used.

Looking at the code, this is occurring because BooleanOptionalArgument has its own code to add default: on its own (instead of leaving formatting as the responsibility of the formatter_class). The code in BooleanOptionalArgument handles less cases where the default should be skipped than the ArgumentDefaultsHelpFormatter code; SUPPRESS is one of the missing cases.

I can see two ways of fixing this:

(1) Remove the code from BooleanOptionalArgument that adds the default values.  It seems to violate the architecture of argparse which delegates modifications to the help message to the formatter_class so this is a special case which could cause issues for future modifications as well.

(2) If the usefulness of outputting the default values without changing the formatter_class is deemed too important to relinquish, then moving the code that ArgumentDefaultsHelpFormatter uses to determine when to skip adding default to the help message can be extracted from ArgumentDefaultsHelpFormatter and called by both ArgumentDefaultsHelpFormatter and BooleanOptionalArgument .

In a review of a fix for https://github.com/python/cpython/pull/17447/files#r429630944 raymond hettinger thought that outputting of the default values was important to keep although I'm not clear on whether he considered that the usefulness comes at the price of possibly violating argparse's architecture.  If he hasn't changed his mind, then #2 is probably the way to resolve this.

I can submit a PR for either of these once I know which direction to take (the first is just removing a few lines of code and I've already written the second one since it seemed like the direction that raymond had last asked for).

Please let me know how you'd like me to proceed.

----------
messages: 397184
nosy: a.badger
priority: normal
severity: normal
status: open
title: BooleanOptionalAction displays default=SUPPRESS unlike other action types
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Jul  9 03:42:56 2021
From: report at bugs.python.org (Ziyue Jiang)
Date: Fri, 09 Jul 2021 07:42:56 +0000
Subject: [New-bugs-announce] [issue44588] Possible double Py_XDECREF in
 cpython typeobject.c
Message-ID: <1625816576.72.0.961811325194.issue44588@roundup.psfhosted.org>


New submission from Ziyue Jiang <ziyue.jiang97 at gmail.com>:

The type_mro_modified() function in Object/typeobject.c may produce double Py_XDECREF on mro_meth and type_mro_meth when enter the code:
if (!_PyType_HasFeature(cls, Py_TPFLAGS_HAVE_VERSION_TAG) ||
!PyType_IsSubtype(type, cls)) {
    goto clear;
}


I think 
mro_meth = NULL;
type_mro_meth = NULL;
should be added after the first time Py_XDECREF them.

----------
components: C API
messages: 397188
nosy: Wesley-Jzy
priority: normal
severity: normal
status: open
title: Possible double Py_XDECREF in cpython typeobject.c
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul  9 06:16:54 2021
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 09 Jul 2021 10:16:54 +0000
Subject: [New-bugs-announce] [issue44589] Pattern Matching - duplicate keys
 in mapping patterns
Message-ID: <1625825814.86.0.0898667876443.issue44589@roundup.psfhosted.org>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

PEP 634 specifies that

"A mapping pattern may not contain duplicate key values. (If all key patterns are literal patterns this is considered a syntax error; otherwise this is a runtime error and will raise ValueError.)"

but this is not what happens with the latest release:

Python 3.10.0b3 (tags/v3.10.0b3:865714a, Jun 17 2021, 20:39:25) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = {'a': 1}
>>> match x:
...  case {'a': 1, 'a': 2}: # (A)
...   print('ok')
...
>>> x = {'a': 3}
>>> match x:
...  case {'a': 1, 'a': 2}: # (B)
...   print('ok')
...
>>> x = {'a': 1, 'b': 2}
>>> match x:
...  case {'a': 1, 'a': 2}: # (C)
...   print('ok')
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ValueError: mapping pattern checks duplicate key ('a')
>>>

If I understand the PEP correctly, all these examples should raise a SyntaxError for the line

case {'a': 1, 'a': 2}:

since all key patterns are literal patterns, and the key 'a' is duplicated.

Cases (A) where the subject matches one of the key-value patterns, and (B) when it doesn't, fail without raising SyntaxError.

Case (C) where one of the keys in the subject is not present in the mapping pattern raises a ValueError at runtime instead of SyntaxError.

This behaviour is tested in test_patma.py:

    def test_patma_251(self):
        x = {"a": 0, "b": 1}
        w = y = z = None
        with self.assertRaises(ValueError):
            match x:
                case {"a": y, "a": z}:
                    w = 0
        self.assertIs(w, None)
        self.assertIs(y, None)
        self.assertIs(z, None)

but this doesn't seem compliant with the specification.

BTW, it's not clear to me why the SyntaxError should be limited to the case when all keys are literal patterns; it could be raised whenever a literal pattern is repeated, even when there are value patterns or a double-star pattern, like in

case {'a': 1, 'a': 2, c.imag, **rest}:

----------
components: Interpreter Core
messages: 397195
nosy: quentel
priority: normal
severity: normal
status: open
title: Pattern Matching - duplicate keys in mapping patterns
versions: Python 3.10

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

From report at bugs.python.org  Fri Jul  9 06:53:40 2021
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 09 Jul 2021 10:53:40 +0000
Subject: [New-bugs-announce] [issue44590] Create frame objects lazily when
 needed
Message-ID: <1625828020.36.0.429011373838.issue44590@roundup.psfhosted.org>


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

In https://bugs.python.org/issue44032 we moved most of the data in the frame stack, that is the locals, stack, and "specials" (globals, builtins, code etc), from the heap allocated stack to a (mostly) contiguous array in memory.
That offered some speed up due to better cache locality, and faster allocation of frame objects (they are now fixed size so can use a simple freelist).

However, data is still split between the stack allocated frame and the heap allocated frame.

We should move the remaining data to the stack and only allocate heap objects lazily when needed for tracebacks and the like. This should improve performance further by removing the vast majority of heap frame allocations and further improving locality of reference.

Not only does this have immediate performance benefits, it also paves the way for even better Python-to-Python calls by allowing stack frames to overlap and pass arguments with the minimal amount of copying and INCREF/DECREF pairs.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 397196
nosy: Mark.Shannon, gvanrossum, pablogsal
priority: normal
severity: normal
status: open
title: Create frame objects lazily when needed
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul  9 08:56:18 2021
From: report at bugs.python.org (Ritav Das)
Date: Fri, 09 Jul 2021 12:56:18 +0000
Subject: [New-bugs-announce] [issue44591] Added man heap push
Message-ID: <1625835378.78.0.790490157019.issue44591@roundup.psfhosted.org>


New submission from Ritav Das <ritavdas at gmail.com>:

Added a heap push method for the max heap invariant and added try except block at the end so the user can import that function from the library.

----------
components: Windows
messages: 397197
nosy: paul.moore, ritavdas, steve.dower, tim.golden, zach.ware
priority: normal
pull_requests: 25627
severity: normal
status: open
title: Added man heap push
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul  9 11:14:18 2021
From: report at bugs.python.org (Akuli)
Date: Fri, 09 Jul 2021 15:14:18 +0000
Subject: [New-bugs-announce] [issue44592] tkinter focus_get() with
 non-tkinter Tk widget
Message-ID: <1625843658.56.0.054020011522.issue44592@roundup.psfhosted.org>


New submission from Akuli <akuviljanen17 at gmail.com>:

The purpose of focus_get() is to return the widget that currently has the focus. It tries to convert its result to a tkinter widget, which can fail, because not all Tk widgets are known to tkinter. Consider this, for example:

    import tkinter

    def print_focused_widget():
        print(repr(root.focus_get()))
        root.after(1000, print_focused_widget)

    root = tkinter.Tk()
    menu = root["menu"] = tkinter.Menu()
    menu.add_cascade(label="Click here", menu=tkinter.Menu())
    print_focused_widget()
    tkinter.mainloop()

Output, with menu clicked after a couple seconds (on Linux):

    None
    <tkinter.Tk object .>
    <tkinter.Tk object .>
    Exception in Tkinter callback
    Traceback (most recent call last):
      File "/home/akuli/.local/lib/python3.10/tkinter/__init__.py", line 1916, in __call__
        return self.func(*args)
      File "/home/akuli/.local/lib/python3.10/tkinter/__init__.py", line 838, in callit
        func(*args)
      File "/home/akuli/porcu/foo.py", line 4, in print_focused_widget
        print(repr(root.focus_get()))
      File "/home/akuli/.local/lib/python3.10/tkinter/__init__.py", line 782, in focus_get
        return self._nametowidget(name)
      File "/home/akuli/.local/lib/python3.10/tkinter/__init__.py", line 1531, in nametowidget
        w = w.children[n]
    KeyError: '#!menu'

Some nametowidget() calls in tkinter/__init__.py already handle this correctly. Consider winfo_children(), for example:

            try:
                # Tcl sometimes returns extra windows, e.g. for
                # menus; those need to be skipped
                result.append(self._nametowidget(child))
            except KeyError:
                pass

----------
components: Tkinter
messages: 397199
nosy: Akuli
priority: normal
severity: normal
status: open
title: tkinter focus_get() with non-tkinter Tk widget
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Jul  9 16:46:32 2021
From: report at bugs.python.org (lormuc)
Date: Fri, 09 Jul 2021 20:46:32 +0000
Subject: [New-bugs-announce] [issue44593] _randbelow_with_getrandbits may
 request an unnecessary random bit
Message-ID: <1625863592.21.0.811014081503.issue44593@roundup.psfhosted.org>


New submission from lormuc <benjamin.petrenko at gmail.com>:

For example, Lib/random.py/Random._randbelow_with_getrandbits(1) should always return 0, as per docstring, but it asks for 1 random bit from getrandbits().

----------
components: Library (Lib)
messages: 397219
nosy: lormuc
priority: normal
severity: normal
status: open
title: _randbelow_with_getrandbits may request an unnecessary random bit
type: resource usage
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul  9 19:59:53 2021
From: report at bugs.python.org (John Belmonte)
Date: Fri, 09 Jul 2021 23:59:53 +0000
Subject: [New-bugs-announce] [issue44594]
 AsyncExitStack.enter_async_context() is mishandling exception __context__
Message-ID: <1625875193.61.0.628325060677.issue44594@roundup.psfhosted.org>


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

Over at the Trio project, we have evidence that `AsyncExitStack.enter_async_context(foo())` is not actually equivalent to `async with foo()` regarding raised exception context.

The symptom is a very long, unhelpful tracebacks because the __context__ of raised exceptions is not set to the expected object.

https://github.com/python-trio/trio/issues/2001

I can't speak to this solution myself, but njsmith suggests this amendment to contextlib:

    saved_context = exc_details[1].__context__
        try:
            raise exc_details[1]
        finally:
            exc_details[1].__context__ = saved_context

----------
components: Library (Lib)
messages: 397230
nosy: John Belmonte, njs
priority: normal
severity: normal
status: open
title: AsyncExitStack.enter_async_context() is mishandling exception __context__

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

From report at bugs.python.org  Sat Jul 10 01:27:56 2021
From: report at bugs.python.org (Jos Dechamps)
Date: Sat, 10 Jul 2021 05:27:56 +0000
Subject: [New-bugs-announce] [issue44595] round() gives wrong result
Message-ID: <1625894876.44.0.790089861054.issue44595@roundup.psfhosted.org>


New submission from Jos Dechamps <jos at dechamps.be>:

round(0.3368655,6) returns 0.336865 instead of 0.336866

----------
messages: 397238
nosy: dechamps
priority: normal
severity: normal
status: open
title: round() gives wrong result
type: behavior

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

From report at bugs.python.org  Sat Jul 10 02:55:40 2021
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Jul 2021 06:55:40 +0000
Subject: [New-bugs-announce] [issue44596] Operand coercion breaks
 MappingProxyType encapsulation
Message-ID: <1625900140.09.0.950032205736.issue44596@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The fast locals proxy implementation for PEP 558 used the existing MappingProxyType implementation as a starting point.

This meant I noticed the following code in the mapping proxy comparison implementation:

======
static PyObject *
mappingproxy_richcompare(mappingproxyobject *v, PyObject *w, int op)
{
    return PyObject_RichCompare(v->mapping, w, op);
}
======

Seeing that code lead to trying the following experiment:

==========
>>> from types import MappingProxyType
>>> d = {}
>>> proxy = MappingProxyType(d)
>>> class Sneaky:
...     def __eq__(self, other):
...         if other is d:
...             raise RuntimeError("Broke encapsulation")
... 
>>> proxy == Sneaky()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __eq__
RuntimeError: Broke encapsulation
==========

The new `__or__` implementation has a corresponding loophole:

========
>>> class SneakyOr:
...     def __or__(self, other):
...         if other is d:
...             raise RuntimeError("Broke encapsulation")
...     def __ror__(self, other):
...         return self.__or__(other)
... 
>>> proxy | SneakyOr()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in __ror__
  File "<stdin>", line 4, in __or__
RuntimeError: Broke encapsulation
========

Delegating these operations to the underlying mapping via the abstract operation layer means that the underlying mapping gets exposed to the operand coercion machinery and can hence be accessed by the other operand.

----------
messages: 397242
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Operand coercion breaks MappingProxyType encapsulation
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Jul 10 07:02:27 2021
From: report at bugs.python.org (Sam Harding)
Date: Sat, 10 Jul 2021 11:02:27 +0000
Subject: [New-bugs-announce] [issue44597] Poll returns POLLOUT on Pipe read
 endpoint on MacOS 10.14
Message-ID: <1625914947.01.0.465830160545.issue44597@roundup.psfhosted.org>


New submission from Sam Harding <samharding42 at gmail.com>:

The behaviour of select.poll() is inconsistent across MacOS versions, on MacOS Mojave (10.14.6) registering and polling the receiving channel of mp.Pipe(duplex=False) returns the event POLLOUT (ready to write to). This is verified by a colleagues setup.

Whereas on MacOS 11 the same scenario will not have poll() return that the receiving channel is ready for writing to (POLLOUT). 

Example:
###
import select
import multiprocessing as mp
recv_end, send_end = mp.Pipe(duplex=False)
poll = select.poll()
poll.register(recv_end)
print(poll.poll(1000))
###

MacOS 10.14.6 Result: 
> [(3,4)]

MacOS 11.0.1 Result:
> []

I am assuming that the MacOS 11 behaviour is should be the expected behaviour, and that the recv connection from a Pipe should never return that it is writable.

This was tested with Python 3.9.4, and 3.7.6.

----------
components: Extension Modules, macOS
messages: 397246
nosy: ned.deily, ronaldoussoren, samh42
priority: normal
severity: normal
status: open
title: Poll returns POLLOUT on Pipe read endpoint on MacOS 10.14
type: behavior
versions: Python 3.7, Python 3.9

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

From report at bugs.python.org  Sun Jul 11 12:19:41 2021
From: report at bugs.python.org (tongxiaoge)
Date: Sun, 11 Jul 2021 16:19:41 +0000
Subject: [New-bugs-announce] [issue44598] test_constructor
 (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault
Message-ID: <1626020381.6.0.201295772935.issue44598@roundup.psfhosted.org>


New submission from tongxiaoge <shixuantong at huawei.com>:

I have reproduced this problem in the latest versions of Python 3.8.11 and 3.9.6. Python 3.8.5 does not have this problem, other versions are not tested. The failure log is as follows?
[  613s] 0:02:27 load avg: 4.66 Re-running failed tests in verbose mode
[  613s] 0:02:27 load avg: 4.66 Re-running test_ssl in verbose mode
[  613s] test_ssl: testing with 'OpenSSL 1.1.1f  31 Mar 2020' (1, 1, 1, 6, 15)
[  613s]           under 'Linux-5.4.6-x86_64-with-glibc2.2.5'
[  613s]           HAS_SNI = True
[  613s]           OP_ALL = 0x80000054
[  613s]           OP_NO_TLSv1_1 = 0x10000000
[  613s] test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
[  613s] test_cert_store_stats (test.test_ssl.ContextTests) ... ok
[  613s] test_check_hostname (test.test_ssl.ContextTests) ... ok
[  613s] test_ciphers (test.test_ssl.ContextTests) ... ok
[  613s] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault
[  613s] 
[  613s] Current thread 0x00007ff433b90740 (most recent call first):
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/ssl.py", line 483 in __new__
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/test_ssl.py", line 1126 in test_constructor
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 650 in _callTestMethod
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 693 in run
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 753 in __call__
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 122 in run
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 84 in __call__
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 122 in run
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 84 in __call__
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/runner.py", line 176 in run
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/support/__init__.py", line 2030 in _run_suite
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/support/__init__.py", line 2152 in run_unittest
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/test_ssl.py", line 4848 in test_main
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 153 in _runtest
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", line 193 in runtest
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 694 in _main
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 637 in main
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 715 in main
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/regrtest.py", line 46 in _main
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/regrtest.py", line 50 in <module>
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/runpy.py", line 87 in _run_code
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/runpy.py", line 194 in _run_module_as_main
[  613s] /var/tmp/rpm-tmp.lFeeM8: line 50: 15891 Segmentation fault      WITHIN_PYTHON_RPM_BUILD= LD_LIBRARY_PATH=$(pwd)/build/debug $(pwd)/build/debug/python -m test.regrtest -wW --slowest -j0 -x test_distutils -x test_bdist_rpm -x test_gdb -x test_socket -x test_asyncio
[  613s] error: Bad exit status from /var/tmp/rpm-tmp.lFeeM8 (%check)

What is the reason for this? and is there a plan to fix it?

----------
assignee: christian.heimes
components: SSL, Tests
messages: 397254
nosy: Guido.van.Rossum, christian.heimes, sxt1001, vstinner
priority: normal
severity: normal
status: open
title: test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jul 11 13:12:20 2021
From: report at bugs.python.org (Amanieu)
Date: Sun, 11 Jul 2021 17:12:20 +0000
Subject: [New-bugs-announce] [issue44599] Changing logging format for one
 handler changes it for all
Message-ID: <1626023540.4.0.759613436664.issue44599@roundup.psfhosted.org>


New submission from Amanieu <hy at hyamani.eu>:

I want to stream a logger to several streams. Changing the standard format works, but changing the formatException function changes it for all!

As I am not entirely sure if it is a feature and I am misunderstanding something, I have posted on SO on this topic: https://stackoverflow.com/questions/68244691/changing-logging-format-for-one-handler-changes-it-for-all

It looks like an unexpected behavior to me when reading the doc.

----------
components: Library (Lib)
messages: 397258
nosy: hyamanieu
priority: normal
severity: normal
status: open
title: Changing logging format for one handler changes it for all
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jul 11 17:02:55 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 11 Jul 2021 21:02:55 +0000
Subject: [New-bugs-announce] [issue44600] match/case statements trace
 incorrectly in 3.10.0b4
Message-ID: <1626037375.68.0.596111226116.issue44600@roundup.psfhosted.org>


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

Some simple match/case statements show incorrect tracing.  Below is the code to run, as well as the output.  Output lines with initial stars are incorrect: they incorrectly indicate that case bodies are executing when they are not. Sorry for the bulk here, I wanted to give you all the cases I had.

-- 8< -------------------------------------
import linecache, sys

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

def match_with_default():
    for command in ["huh", "go home", "go n"]:
        print(command)
        match command.split():
            case ["go", direction] if direction in "nesw":
                match = f"go: {direction}"
            case ["go", _]:
                match = "no go"
            case _:
                match = "default"
        print(match)

def match_with_wildcard():
    for command in ["huh", "go home", "go n"]:
        print(command)
        match command.split():
            case ["go", direction] if direction in "nesw":
                match = f"go: {direction}"
            case ["go", _]:
                match = "no go"
            case x:
                match = f"default: {x}"
        print(match)

def match_without_wildcard():
    match = None
    for command in ["huh", "go home", "go n"]:
        print(command)
        match command.split():
            case ["go", direction] if direction in "nesw":
                match = f"go: {direction}"
            case ["go", _]:
                match = "no go"
        print(match)

print(sys.version)
sys.settrace(trace)
match_with_default()
match_with_wildcard()
match_without_wildcard()
-- 8< -------------------------------------
Output:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 10: def match_with_default():
  line 11:     for command in ["huh", "go home", "go n"]:
  line 12:         print(command)
  huh
  line 13:         match command.split():
  line 14:             case ["go", direction] if direction in "nesw":
  line 15:                 match = f"go: {direction}"
  line 16:             case ["go", _]:
* line 17:                 match = "no go"
  line 19:                 match = "default"
  line 20:         print(match)
  default
  line 11:     for command in ["huh", "go home", "go n"]:
  line 12:         print(command)
  go home
  line 13:         match command.split():
  line 14:             case ["go", direction] if direction in "nesw":
  line 16:             case ["go", _]:
  line 17:                 match = "no go"
  line 20:         print(match)
  no go
  line 11:     for command in ["huh", "go home", "go n"]:
  line 12:         print(command)
  go n
  line 13:         match command.split():
  line 14:             case ["go", direction] if direction in "nesw":
  line 15:                 match = f"go: {direction}"
  line 20:         print(match)
  go: n
  line 11:     for command in ["huh", "go home", "go n"]:
  retu 11:     for command in ["huh", "go home", "go n"]:
  call 22: def match_with_wildcard():
  line 23:     for command in ["huh", "go home", "go n"]:
  line 24:         print(command)
  huh
  line 25:         match command.split():
  line 26:             case ["go", direction] if direction in "nesw":
* line 27:                 match = f"go: {direction}"
  line 28:             case ["go", _]:
* line 29:                 match = "no go"
  line 30:             case x:
  line 31:                 match = f"default: {x}"
  line 32:         print(match)
  default: ['huh']
  line 23:     for command in ["huh", "go home", "go n"]:
  line 24:         print(command)
  go home
  line 25:         match command.split():
  line 26:             case ["go", direction] if direction in "nesw":
  line 28:             case ["go", _]:
  line 29:                 match = "no go"
  line 32:         print(match)
  no go
  line 23:     for command in ["huh", "go home", "go n"]:
  line 24:         print(command)
  go n
  line 25:         match command.split():
  line 26:             case ["go", direction] if direction in "nesw":
  line 27:                 match = f"go: {direction}"
  line 32:         print(match)
  go: n
  line 23:     for command in ["huh", "go home", "go n"]:
  retu 23:     for command in ["huh", "go home", "go n"]:
  call 34: def match_without_wildcard():
  line 35:     match = None
  line 36:     for command in ["huh", "go home", "go n"]:
  line 37:         print(command)
  huh
  line 38:         match command.split():
  line 39:             case ["go", direction] if direction in "nesw":
* line 40:                 match = f"go: {direction}"
  line 41:             case ["go", _]:
* line 42:                 match = "no go"
  line 43:         print(match)
  None
  line 36:     for command in ["huh", "go home", "go n"]:
  line 37:         print(command)
  go home
  line 38:         match command.split():
  line 39:             case ["go", direction] if direction in "nesw":
  line 41:             case ["go", _]:
  line 42:                 match = "no go"
  line 43:         print(match)
  no go
  line 36:     for command in ["huh", "go home", "go n"]:
  line 37:         print(command)
  go n
  line 38:         match command.split():
  line 39:             case ["go", direction] if direction in "nesw":
  line 40:                 match = f"go: {direction}"
  line 43:         print(match)
  go: n
  line 36:     for command in ["huh", "go home", "go n"]:
  retu 36:     for command in ["huh", "go home", "go n"]:

----------
components: Interpreter Core
messages: 397264
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: match/case statements trace incorrectly in 3.10.0b4
versions: Python 3.10

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

From report at bugs.python.org  Sun Jul 11 19:21:14 2021
From: report at bugs.python.org (Xiang Zhong)
Date: Sun, 11 Jul 2021 23:21:14 +0000
Subject: [New-bugs-announce] [issue44601] argparse: potential bugs on
 add_subparser due to allow_abbrev cannot deal with short options
Message-ID: <1626045674.23.0.119206602345.issue44601@roundup.psfhosted.org>


New submission from Xiang Zhong <zhongxiang117 at gmail.com>:

Additional argument like "allow_abbrev_short" should be added to avoid those potential bugs due to abbreviations on short options cannot be handled by "allow_abbrev".

To reproduce and be well explanation, please check on my attached testing file.

The following is the excerpt:

1) contents in link:
   https://docs.python.org/3/library/argparse.html#prefix-matching
   should be updated to long options (two dashes)

2) bugs may happen due to `allow_abbrev' cannot handle short options
   when recycling top-level arguments by using `add_subparsers'

----------
components: Library (Lib)
files: myargparse.py
messages: 397268
nosy: zhongxiang117
priority: normal
severity: normal
status: open
title: argparse: potential bugs on add_subparser due to allow_abbrev cannot deal with short options
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50143/myargparse.py

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

From report at bugs.python.org  Sun Jul 11 19:25:02 2021
From: report at bugs.python.org (Rajesh)
Date: Sun, 11 Jul 2021 23:25:02 +0000
Subject: [New-bugs-announce] [issue44602] Issue with get_build_version in
 msvc9compiler.py in distutils
Message-ID: <1626045902.73.0.895322421093.issue44602@roundup.psfhosted.org>


New submission from Rajesh <mailkalyan23 at gmail.com>:

get_build_version method in msvc9compiler.py file in distutils folder is returning MSVC version as "14.2" for Python 3.9.

14.2 is the build version for Visual Studio 2015, but Visual studio 2015 wont work on Windows 10 as per the below link 

https://visualstudio.microsoft.com/vs/support/vs2015/visual-studio-2015-system-requirements/

So, Python 3.9 wont work on Windows 10?

I am trying to install wxPython 4.0.7 using "pip install wxPython==4.0.7" but facing error to find the visual studio in Windows 10 using Python 3

----------
messages: 397269
nosy: kalyan
priority: normal
severity: normal
status: open
title: Issue with get_build_version in msvc9compiler.py in distutils
type: behavior

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

From report at bugs.python.org  Sun Jul 11 23:15:54 2021
From: report at bugs.python.org (Aritn Sarraf)
Date: Mon, 12 Jul 2021 03:15:54 +0000
Subject: [New-bugs-announce] [issue44604] [Enhancement] Asyncio task
 decorator to provide functionality similar to dask's delayed interface
Message-ID: <1626059754.28.0.00554951175924.issue44604@roundup.psfhosted.org>


New submission from Aritn Sarraf <sarraf.artin at gmail.com>:

For those not familiar, the dask delayed interface allows a user to define a DAG through a functional invocation interface. Dask docs here: https://docs.dask.org/en/latest/delayed.html
Another example of this kind of interface is airflow's new TaskFlow api: https://airflow.apache.org/docs/apache-airflow/stable/concepts/taskflow.html

The proposed solution would look something like this. Essentially all we're doing is defining a decorator that will allow you to pass in coroutines to another coroutine, and will resolve the dependent coroutines before passing the results to your dependent coroutine.

    # Note0: can be removed, see Note2 below
    async def task_wrapper(val):
        return val

    def task(afunc):  # open to other names for the decorator since it might be a bit ambiguous
        async def inner(*args):  # Note1: real solution would be expanded to args/kwargs
            # Note2: `task_wrapper` kind of unneccesary, we can just conditionally not gather in those cases
            args = [arg if inspect.isawaitable(arg) else task_wrapper(arg) for arg in args]
            args = await asyncio.gather(*args)
            return await afunc(*args)
        return inner


The advantage this gives us in asyncio is that we can easily build processing pipelines where each piece is completely independent and does not know anything about any other piece of the pipeline. Obviously this is already possible currently, but this simple wrapper will provide a very clean way to connect it all together.

Take the following example, where we want to fetch data for various ids and post process/upload them.

    @task
    async def fetch(x):
        # Note3: timings here defined to demo obvious expected async behavior in completion order of print statements
        sleep_time = {'a1': 1, 'a2': 2, 'b1': 4, 'b2': 0.5, 'c1': 6, 'c2': 3.5}[x]
        await asyncio.sleep(sleep_time)
        ret_val = f'f({x})'
        print(f'Done {ret_val}')
        return ret_val

    async def process(x1, x2):
        await asyncio.sleep(1)
        ret_val = f'p({x1}, {x2})'
        print(f'Done {ret_val}')
        return ret_val

Notice we didn't decorate `process`, this is to allow us to demonstrate how you can still use the interface on functions that you can't or don't want to decorate. Now to define/execute our pipeline we can simply do this. :


    async def main():
        fa1 = fetch('a1')
        fa2 = fetch('a2')
        fb1 = fetch('b1')
        fb2 = fetch('b2')
        fc1 = fetch('c1')
        fc2 = fetch('c2')
        pa = task(process)(fa1, fa2)
        pb = task(process)(fb1, fb2)
        pc = task(process)(fc1, fc2)
        return await asyncio.gather(pa, pb, pc)
 
    loop = asyncio.new_event_loop()
    loop.run_until_complete(main())

This will be a very simple non-breaking inclusion to the library, that will allow users to build clean/straightforward asynchronous processing pipelines/DAGs.

----------
components: asyncio
messages: 397274
nosy: asarraf, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: [Enhancement] Asyncio task decorator to provide functionality similar to dask's delayed interface
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Jul 11 23:15:45 2021
From: report at bugs.python.org (Stargirl Flowers)
Date: Mon, 12 Jul 2021 03:15:45 +0000
Subject: [New-bugs-announce] [issue44603] REPL: exit when the user types
 exit instead of asking them to explicitly type exit()
Message-ID: <1626059745.58.0.0764234383007.issue44603@roundup.psfhosted.org>


New submission from Stargirl Flowers <me at thea.codes>:

Presently, when using REPL if a user types simply "exit", they are greeted with a message instructing them to do it "correctly":

>>> exit
Use exit() or Ctrl-Z plus Return to exit

It comes across as a little surprising that (1) the program knows what I meant and (2) the program told me it wouldn't do it unless I request it in a very specific way. This isn't very user-friendly behavior.

Further surprising is the inconsistent behavior of the other built-ins described on interpreter start-up. "copyright" and "credits" work fine without being invoked as a function, whereas "help" and "license" rebuff the user. 

I know there are compelling technical reasons for the current behavior, however, this behavior is a bit off-putting for newcomers. Knowing the technical reasons behind this behavior made me *more* frustrated than less frustrated.

Python is a lovely language and I think we should do what we can to be friendlier to users. I propose a few changes to fix this specific issue:

(1) Include "exit" in the interpreter startup message, making it: Type "help", "copyright", "credits" or "license" for more information, and type "exit" to quit Python.

(2) Make the interactive interpreter exit when the user types simply "exit" or "quit.

To address some possible edge cases an objections:

- if (2) proves too controversial, we should at least do (1) with the slight modification of "exit" to "exit()".
- if there is a concern about accidentally exiting the interpreter, there are several strategies we can use. First, we can only activate this behavior if, and only if, Python is being used as an interactive interpreter. From what I can tell, main() is already distinguishing this case. Second, if absolutely necessary we could ask the user to confirm that they want to exit. For example:

>>> exit
Are you sure you want to exit Python? (yes/no): 

For what it's worth, I am willing to do this work, however, I might need a little guidance to find the right bits.

----------
components: Demos and Tools
messages: 397273
nosy: theacodes
priority: normal
severity: normal
status: open
title: REPL: exit when the user types exit instead of asking them to explicitly type exit()

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

From report at bugs.python.org  Mon Jul 12 01:21:05 2021
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Mon, 12 Jul 2021 05:21:05 +0000
Subject: [New-bugs-announce] [issue44605] functools.total_ordering doesn't
 work with metaclasses
Message-ID: <1626067265.0.0.995880932731.issue44605@roundup.psfhosted.org>


New submission from Glyph Lefkowitz <glyph at twistedmatrix.com>:

Consider the following example that attempts to make a series of types sortable by their class name:




from functools import total_ordering

@total_ordering
class SortableMeta(type):
    def __new__(cls, name, bases, ns):
        return super().__new__(cls, name, bases, ns)

    def __lt__(self, other):
        if not isinstance(other, SortableMeta):
            pass
        return self.__name__ < other.__name__

    def __eq__(self, other):
        if not isinstance(other, SortableMeta):
            pass
        return self.__name__ == other.__name__

class B(metaclass=SortableMeta):
    pass

class A(metaclass=SortableMeta):
    pass


print(A < B)
print(A > B)


This should just print "True", "False", but instead the second comparison raises this exception:

Traceback (most recent call last):
  File "total_ordering_metaclass.py", line 27, in <module>
    print(A > B)
  File "lib/python3.9/functools.py", line 91, in _gt_from_lt
    op_result = self.__lt__(other)
TypeError: expected 1 argument, got 0


The problem here is that functools considers .__special__ to be equivalent to operator.special.  I'm pretty sure this should be invoking "self < other" rather than self.__lt__(other).

----------
components: Library (Lib)
messages: 397278
nosy: glyph
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.total_ordering doesn't work with metaclasses
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul 12 01:33:30 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Jul 2021 05:33:30 +0000
Subject: [New-bugs-announce] [issue44606] Discrepancy between isinstance()
 and issubclass() for union types
Message-ID: <1626068010.0.0.827203286312.issue44606@roundup.psfhosted.org>


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

1. Different handling of None:

>>> isinstance(None, int | type(None))
True
>>> issubclass(type(None), int | type(None))
True
>>> isinstance(None, int | None)
True
>>> issubclass(type(None), int | None)
False

2. Different handling of virtual subclasses:

>>> import collections.abc
>>> isinstance({}, int | collections.abc.Mapping)
True
>>> issubclass(dict, int | collections.abc.Mapping)
False

I do not know what behavior is correct.

----------
components: Interpreter Core
messages: 397281
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Discrepancy between isinstance() and issubclass() for union types
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Jul 12 02:48:56 2021
From: report at bugs.python.org (Muffinlicious)
Date: Mon, 12 Jul 2021 06:48:56 +0000
Subject: [New-bugs-announce] [issue44607] Teleport method for turtle class
Message-ID: <1626072536.55.0.653021323155.issue44607@roundup.psfhosted.org>


New submission from Muffinlicious <alicornderpy at gmail.com>:

I use turtle pretty often in a teaching setting. It's extremely common that I'll define the following function at the top of my code:

def teleport(x, y):
    turtle.penup()
    turtle.setpos(x, y)
    turtle.pendown()

Shouldn't this sort of method already exist within the turtle class?

----------
components: Tkinter
messages: 397286
nosy: Muffinlicious
priority: normal
severity: normal
status: open
title: Teleport method for turtle class
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Jul 12 03:00:30 2021
From: report at bugs.python.org (stardust222)
Date: Mon, 12 Jul 2021 07:00:30 +0000
Subject: [New-bugs-announce] [issue44608] Memory use increase in function
 _tkinter._flatten
Message-ID: <1626073230.86.0.981576965453.issue44608@roundup.psfhosted.org>


New submission from stardust222 <490661700 at qq.com>:

In the following code, the memory use of function _tkinter._flatten is increase as the number of calls when I input an illegal value.


import sys
import tracemalloc
import _tkinter

arg_list = []
arg_list.append('ptqiioaaejhdoat')

# check for memory usage
memory_recorder = []
tracemalloc.start()
start_snapshot = tracemalloc.take_snapshot()
for i in range(0, 100):
  try:
    _tkinter._flatten(arg_list[0])
  except:
    pass
  if i % 10 == 0:
    one_snapshot = tracemalloc.take_snapshot()
    memory_recorder.append(one_snapshot.compare_to(start_snapshot, 'lineno')[0])

for i in range(2, len(memory_recorder)):
  if str(memory_recorder[i].traceback) == str(memory_recorder[1].traceback):
    print(memory_recorder[i].traceback)
    print(memory_recorder[i].size)

tracemalloc.stop()

And the output on my machine is 
test.py:19
3248
test.py:19
4800
test.py:19
6448
test.py:19
8000
test.py:19
9648
test.py:19
11248
test.py:19
12848
test.py:19
14400

----------
components: C API
messages: 397287
nosy: Stardust1225
priority: normal
severity: normal
status: open
title: Memory use increase in function _tkinter._flatten
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Mon Jul 12 11:05:02 2021
From: report at bugs.python.org (Tarun Johar)
Date: Mon, 12 Jul 2021 15:05:02 +0000
Subject: [New-bugs-announce] [issue44609] Buffer support in the stable ABI
Message-ID: <1626102302.84.0.543468149442.issue44609@roundup.psfhosted.org>


New submission from Tarun Johar <tarun.johar at gmail.com>:

PEP 384 and PEP 652 define a stable ABI to be used with Python 3.2 and later.  On Windows, symbols for the stable ABI are exported from the python3.dll shared library.

The following functions are present in Python 3.9 but have been removed from Python 3.10b3:

PyObject_AsCharBuffer()
PyObject_AsReadBuffer()
PyObject_AsWriteBuffer()
PyObject_CheckReadBuffer()

The justification for the removal of these functions was discussed in this issue:

https://bugs.python.org/issue41103

Without these functions, an extension cannot utilize the stable ABI to access the buffer memory of data structures.  The buffer protocol is suggested as an alternative, but the buffer functions PyObject_GetBuffer() and PyBuffer_Release() are not present in the stable ABI.

While these two functions may be added to the stable ABI, removal of the four functions above makes Python 3.10 incompatible with previous versions.  It is requested that the four functions be reinstated and maintained as described in PEP 652.

----------
components: Build
messages: 397319
nosy: tarun.johar
priority: normal
severity: normal
status: open
title: Buffer support in the stable ABI
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Jul 12 11:23:50 2021
From: report at bugs.python.org (Bartosz Kaznowski)
Date: Mon, 12 Jul 2021 15:23:50 +0000
Subject: [New-bugs-announce] [issue44610] Format issue with strftime and %Y
Message-ID: <1626103430.53.0.693000893049.issue44610@roundup.psfhosted.org>


New submission from Bartosz Kaznowski <bartekkaznowski at gmail.com>:

When you convert a date pre the year 1000 to a string with `%Y` as the formatter and then back to a date again then it fails. This is because `%Y` expects it to be formatted with leading zeroes. For example, the year 1/01/01 (yyyy/mm/dd) should be 0001/01/01 when formatting using %Y/%m/%d. However, %Y returns 1.
You can see this in action here:

from datetime import date, datetime
format = "%Y-%m-%d"
formatted = date.min.strftime("%Y-%m-%d")
datetime.strptime(formatted, format).date()

`ValueError: time data '1-01-01' does not match format '%Y-%m-%d'` is raised on the forth line.

----------
components: Library (Lib)
messages: 397329
nosy: bkaznowski
priority: normal
severity: normal
status: open
title: Format issue with strftime and %Y
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Jul 12 13:16:33 2021
From: report at bugs.python.org (Dan Stromberg)
Date: Mon, 12 Jul 2021 17:16:33 +0000
Subject: [New-bugs-announce] [issue44611] CPython uses deprecated randomness
 API
Message-ID: <1626110193.36.0.138157170892.issue44611@roundup.psfhosted.org>


New submission from Dan Stromberg <strombrg at gmail.com>:

CPython 3.9 uses CryptGenRandom(), which has been deprecated by Microsoft.

I'm told the randomness produced by CryptGenRandom() is fine, but Microsoft has introduced a newer API for getting randomness.

For these reasons, Python/bootstrap_hash.c should be updated to use https://docs.microsoft.com/en-us/windows/win32/seccng/cng-por , but it is not urgent, and is not needed in older versions of CPython.

Also the documentation that references CryptGenRandom() should be updated, EG: https://docs.python.org/3/library/os.html#os.urandom

----------
components: Windows
messages: 397339
nosy: paul.moore, steve.dower, strombrg, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: CPython uses deprecated randomness API
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Jul 12 14:34:00 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Mon, 12 Jul 2021 18:34:00 +0000
Subject: [New-bugs-announce] [issue44612] inspect module points that could
 be using f-String
Message-ID: <1626114840.28.0.434964034307.issue44612@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

There are some points in inspect module (I counted 48 since version 3.7) that could be using f-String formatting instead of format().

Changing these points will improve code readability, it will also decrease the complexity at these points and not to mention the fact that f-String formatting has better performance.

Obs.: Many other points could receive this improvement in other modules. This would provide the improvements I mentioned earlier, especially in older snippets of code.

----------
components: Library (Lib)
messages: 397343
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: inspect module points that could be using f-String
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul 12 14:38:10 2021
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Jul 2021 18:38:10 +0000
Subject: [New-bugs-announce] [issue44613] Make importlib.metadata
 non-provisional in Python 3.10
Message-ID: <1626115090.32.0.857844530408.issue44613@roundup.psfhosted.org>


New submission from Barry A. Warsaw <barry at python.org>:

As discussed with Jason, importlib.metadata will be made non-provisional in 3.10.  I have a PR in the works for this.

----------
assignee: barry
components: Documentation
messages: 397344
nosy: barry, jaraco
priority: normal
severity: normal
status: open
title: Make importlib.metadata non-provisional in Python 3.10
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Jul 12 18:07:45 2021
From: report at bugs.python.org (Florian Streibelt)
Date: Mon, 12 Jul 2021 22:07:45 +0000
Subject: [New-bugs-announce] [issue44614] Broken Pipe in Server of Manager
 in multiprocessing when finalizing, sometimes
Message-ID: <1626127665.43.0.394299771131.issue44614@roundup.psfhosted.org>


New submission from Florian Streibelt <github at f-streibelt.de>:

It seems that the shutdown() method of the Server in in managers.py is already sending the result of its execution directly into the connection, and then the handle_request() method is trying to send ('#RETURN', None) yet again after returning from the call to shutdown() which sometimes yields a Broken Pipe Exception.

with the following line in handle_request():
    result = func(c, *args, **kwds)
a call to shutown() is made, and in shutdown() I see:
    c.send(('#RETURN', None))

and back in handle_request():
    msg = ('#RETURN', result)
?
    c.send(msg)

attached you find a minimal example that shows this behaviour sometimes, if logging is set to not more than DEBUG. I am guessing that the Broken Pipe depends on a race with the other side being closed.

Although the race condition does not look like having an impact, it is highly confusing when debugging. 


log:
      INFO           MainProcess         util.py:54  sending shutdown message to manager
     DEBUG        BaseManager-12         util.py:50  manager received shutdown message
      INFO        BaseManager-12         util.py:54  Failure to send message: ('#RETURN', None)
      INFO        BaseManager-12         util.py:54  process shutting down
      INFO        BaseManager-12         util.py:54   ... request was (None, 'shutdown', (), {})
     DEBUG        BaseManager-12         util.py:50  running all "atexit" finalizers with priority >= 0
      INFO        BaseManager-12         util.py:54   ... exception was BrokenPipeError(32, 'Broken pipe')
     DEBUG        BaseManager-12         util.py:50  running the remaining "atexit" finalizers
      INFO        BaseManager-12         util.py:54  process exiting with exitcode 0

----------
components: Library (Lib)
files: race2.py
messages: 397358
nosy: mutax
priority: normal
severity: normal
status: open
title: Broken Pipe in Server of Manager in multiprocessing when finalizing, sometimes
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50145/race2.py

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

From report at bugs.python.org  Mon Jul 12 18:18:36 2021
From: report at bugs.python.org (Florian Streibelt)
Date: Mon, 12 Jul 2021 22:18:36 +0000
Subject: [New-bugs-announce] [issue44615] Multiprocessing Pool example and
 comments incomplete/wrong?
Message-ID: <1626128316.93.0.838560232198.issue44615@roundup.psfhosted.org>


New submission from Florian Streibelt <github at f-streibelt.de>:

The docs at the url

https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing.pool

state in a red warning box:

"Warning

multiprocessing.pool objects have internal resources that need to be properly managed (like any other resource) by using the pool as a context manager or by calling close() and terminate() manually. Failure to do this can lead to the process hanging on finalization."


however, when using the context manager, as it is also shown in the examples, the context manager will call terminate() instead of close() and join() on the pool, possible leading to deadlocks if I understand the documentation correct.

It seems the only safe way of using a Pool as Context Manager is to manually call pool.close() and pool.join() prior to leaving it, which, to be honest, does not make sense to me.


see pool.py:

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.terminate()

----------
assignee: docs at python
components: Documentation
messages: 397360
nosy: docs at python, mutax
priority: normal
severity: normal
status: open
title: Multiprocessing Pool example and comments incomplete/wrong?
versions: Python 3.9

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

From report at bugs.python.org  Mon Jul 12 18:51:39 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 12 Jul 2021 22:51:39 +0000
Subject: [New-bugs-announce] [issue44616] Incorrect tracing for "except"
 with variable
Message-ID: <1626130299.77.0.916237528648.issue44616@roundup.psfhosted.org>


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

This construct isn't traced properly:

    except ExceptionName as var:
        if something:
            raise

Here's a reproducer:

-- 8< ---------------------------------
import linecache, sys

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

def f(x):
    try:
        1/0
    except ZeroDivisionError as error:
        if x:
            raise
    return 12

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

for x in [0, 1]:
    try:
        print(f(x))
    except:
        print("oops")
-----------------------------------

When run with 3.10.0b4, it produces this output:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 10: def f(x):
  line 11:     try:
  line 12:         1/0
  exce 12:         1/0
  line 13:     except ZeroDivisionError as error:
  line 14:         if x:
* line 15:             raise
  line 16:     return 12
  retu 16:     return 12
  12
  call 10: def f(x):
  line 11:     try:
  line 12:         1/0
  exce 12:         1/0
  line 13:     except ZeroDivisionError as error:
  line 14:         if x:
  line 15:             raise
  retu 15:             raise
  oops

The starred line claims that raise is being run, but it is not run at that point.

The variable on the except clause is important.  If you change that line to "except ZeroDivisionError:", then the output is correct:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 10: def f(x):
  line 11:     try:
  line 12:         1/0
  exce 12:         1/0
  line 13:     except ZeroDivisionError:
  line 14:         if x:
  line 16:     return 12
  retu 16:     return 12
  12
  call 10: def f(x):
  line 11:     try:
  line 12:         1/0
  exce 12:         1/0
  line 13:     except ZeroDivisionError:
  line 14:         if x:
  line 15:             raise
  retu 15:             raise
  oops

----------
components: Interpreter Core
keywords: 3.10regression
messages: 397365
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Incorrect tracing for "except" with variable
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Jul 12 23:34:48 2021
From: report at bugs.python.org (Pablo Aguilar)
Date: Tue, 13 Jul 2021 03:34:48 +0000
Subject: [New-bugs-announce] [issue44617] Undesired Behavior on `match`
 using Singleton object
Message-ID: <1626147288.08.0.390931510004.issue44617@roundup.psfhosted.org>


New submission from Pablo Aguilar <pablo.aguilar at fatec.sp.gov.br>:

Hey, I'm not sure if this is really a bug but I'd like to show to prevent some undesired behavior!

I'm working in the `match` support for returns (https://github.com/dry-python/returns) library when I saw a behavior similar to the described in `Constant Value Patterns` section on PEP-622 (https://www.python.org/dev/peps/pep-0622/#constant-value-patterns).

A very small and reproducible example:
```python
from typing import Any, ClassVar, Optional


class Maybe:
    empty: ClassVar['Maybe']
    _instance: Optional['Maybe'] = None

    def __new__(cls, *args: Any, **kwargs: Any) -> 'Maybe':
        if cls._instance is None:
            cls._instance = object.__new__(cls)
        return cls._instance


Maybe.empty = Maybe()


if __name__ == '__main__':
    my_maybe = Maybe()
    match my_maybe:
        case Maybe.empty:
            print('FIRST CASE')
        case _:
            print('DEFAULT CASE')
```

The output here is `FIRST CASE`, but if I delete `__new__` method the output is `DEFAULT CASE`.

Is that the correct behavior?

Python version: 3.10.0a7

----------
components: Interpreter Core
messages: 397380
nosy: thepabloaguilar
priority: normal
severity: normal
status: open
title: Undesired Behavior on `match` using Singleton object
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Jul 13 03:41:18 2021
From: report at bugs.python.org (Mauricio Villegas)
Date: Tue, 13 Jul 2021 07:41:18 +0000
Subject: [New-bugs-announce] [issue44618] inspect.signature does not work
 for datetime classes
Message-ID: <1626162078.24.0.194319586599.issue44618@roundup.psfhosted.org>


New submission from Mauricio Villegas <mauricio_ville at yahoo.com>:

Classes in the datetime module are implemented using __new__ with some named parameters. I want to be able to inspect their signature to know which are the names of the parameters it accepts like it works for most classes. However, this does not work for classes in the datetime module. I already mentioned this in https://bugs.python.org/issue40897 but now I am thinking this should be a separate issue so I am creating this one.

An example is the class timedelta. It has as parameters days, seconds, microseconds, milliseconds, minutes, hours and weeks. If I run the following script trying different python versions

for py in 36 37 38 39; do
  source py${py}/bin/activate
  echo "=== $(python3 --version) ==="
  python3 -c "
from datetime import timedelta
import inspect
print(inspect.signature(timedelta.__new__))
print(inspect.signature(timedelta.__init__))
inspect.signature(timedelta)
"
  deactivate
done

What I get is

=== Python 3.6.9 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>
=== Python 3.7.11 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>
=== Python 3.8.11 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>
=== Python 3.9.6 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>

----------
messages: 397387
nosy: mauvilsa
priority: normal
severity: normal
status: open
title: inspect.signature does not work for datetime classes
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jul 13 06:48:49 2021
From: report at bugs.python.org (Prakash)
Date: Tue, 13 Jul 2021 10:48:49 +0000
Subject: [New-bugs-announce] [issue44619] Bug in Python 3.7.10
Message-ID: <1626173329.18.0.223502644696.issue44619@roundup.psfhosted.org>


New submission from Prakash <prakashvm at gmail.com>:

Hello -

I wish to bring to your kind notice a bug in Python.

Given any matrix X. While trying to compute the CoVariance matrix of that matrix X, Python does NOT compute the CoVarianceof the given matrix X.

Instead, Python comptes the CoVariance of the Transpose of the given matrix X.

This appears to be a bug in Python.

Please refer to the below website for a given matrix and what the result should be after the computation of it's CoVariance. And I have provided a screenshot of what Python is returning.

https://www.itl.nist.gov/div898/handbook/pmc/section5/pmc541.htm


Please let me know if you have any questions.



Regards,
Prakash

----------
files: Bug in Python.pdf
messages: 397390
nosy: prakashvm
priority: normal
severity: normal
status: open
title: Bug in Python 3.7.10
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file50146/Bug in Python.pdf

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

From report at bugs.python.org  Tue Jul 13 07:15:00 2021
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgR8O2csO2Zw==?=)
Date: Tue, 13 Jul 2021 11:15:00 +0000
Subject: [New-bugs-announce] [issue44620] UUIDv1 is not RFC 4122 compliant
Message-ID: <1626174900.35.0.48984459296.issue44620@roundup.psfhosted.org>


New submission from L?szl? G?r?g <contact at nergal.xyz>:

Section 4.1.5 of RFC 4122 says the following about Clock Sequence:

   If the clock is set backwards, or might have been set backwards
   (e.g., while the system was powered off), and the UUID generator can
   not be sure that no UUIDs were generated with timestamps larger than
   the value to which the clock was set, then the clock sequence has to
   be changed.  If the previous value of the clock sequence is known, it
   can just be incremented; otherwise it should be set to a random or
   high-quality pseudo-random value.

However, the current implementation increments the timestamp and not the clock sequence. Ref: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/uuid.py#L689-L690

----------
components: Library (Lib)
messages: 397392
nosy: contact2
priority: normal
severity: normal
status: open
title: UUIDv1 is not RFC 4122 compliant
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jul 13 07:29:22 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 13 Jul 2021 11:29:22 +0000
Subject: [New-bugs-announce] [issue44621] Python 3.9 traces async for/else
 incorrectly
Message-ID: <1626175762.98.0.836185243325.issue44621@roundup.psfhosted.org>


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

Python 3.9 traces this code incorrectly.  Note: 3.8 and 3.10 are correct, only 3.9 gets it wrong.

-----------------------------------
import linecache, sys

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

import asyncio

async def async_gen():
    yield 13

async def async_test():
    global a
    a = 17
    async for i in async_gen():
        print(i + 19)
    else:
        a = 21

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

asyncio.run(async_test())
assert a == 21
----------------------------------

The starred line shows a trace of a statement that is not executed:

  3.9.6 (default, Jul 13 2021, 07:21:14)
  [Clang 12.0.0 (clang-1200.0.32.29)]
  call 15: async def async_test():
  line 17:     a = 17
  line 18:     async for i in async_gen():
  call 12: async def async_gen():
  line 13:     yield 13
  retu 13:     yield 13
  exce 18:     async for i in async_gen():
  line 19:         print(i + 19)
  32
  line 18:     async for i in async_gen():
  call 13:     yield 13
  retu 13:     yield 13
  exce 18:     async for i in async_gen():
* line 19:         print(i + 19)
  line 21:         a = 21
  retu 21:         a = 21

----------
components: Interpreter Core
keywords: 3.9regression
messages: 397393
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Python 3.9 traces async for/else incorrectly
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 13 09:03:51 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 13 Jul 2021 13:03:51 +0000
Subject: [New-bugs-announce] [issue44622] async-for loops are traced
 incorrectly in Python 3.10
Message-ID: <1626181431.87.0.924795967065.issue44622@roundup.psfhosted.org>


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

In Python 3.10, the traces at the end of an async-for loop are incorrect and different than at the end of a for-loop.

------------------------------
import linecache, sys

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

import asyncio

class AsyncIter:
    def __init__(self, items): self.items = items

    async def __aiter__(self):
        for i in self.items: yield i

async def test1():
    async for i in AsyncIter([1]):
        print(f"test1 {i}")

def test2():
    for i in [1]:
        print(f"test2 {i}")

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

asyncio.run(test1())
test2()
------------------------------------

In 3.7, 3.8 and 3.9, the two for loops behave the same: the loop jumps back to the "for" statement, and then returns (the arrowed lines):

  3.9.5 (default, May  5 2021, 06:50:43)
  [Clang 12.0.0 (clang-1200.0.32.29)]
  call 18: async def test1():
  line 19:     async for i in AsyncIter([1]):
  call 13:     def __init__(self, items): self.items = items
  line 13:     def __init__(self, items): self.items = items
  retu 13:     def __init__(self, items): self.items = items
  call 15:     async def __aiter__(self):
  line 16:         for i in self.items: yield i
  retu 16:         for i in self.items: yield i
  exce 19:     async for i in AsyncIter([1]):
  line 20:         print(f"test1 {i}")
  test1 1
  line 19:     async for i in AsyncIter([1]):
  call 16:         for i in self.items: yield i
  line 16:         for i in self.items: yield i
  retu 16:         for i in self.items: yield i
  exce 19:     async for i in AsyncIter([1]):
> retu 19:     async for i in AsyncIter([1]):
  call 22: def test2():
  line 23:     for i in [1]:
  line 24:         print(f"test2 {i}")
  test2 1
  line 23:     for i in [1]:
> retu 23:     for i in [1]:


In 3.10, the for loop behaves the same, but now the async-for traces the body once more when it doesn't execute, and returns from the body of the loop (the starred line):

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 18: async def test1():
  line 19:     async for i in AsyncIter([1]):
  call 13:     def __init__(self, items): self.items = items
  line 13:     def __init__(self, items): self.items = items
  retu 13:     def __init__(self, items): self.items = items
  call 15:     async def __aiter__(self):
  line 16:         for i in self.items: yield i
  retu 16:         for i in self.items: yield i
  exce 19:     async for i in AsyncIter([1]):
  line 20:         print(f"test1 {i}")
  test1 1
  line 19:     async for i in AsyncIter([1]):
  call 16:         for i in self.items: yield i
  line 16:         for i in self.items: yield i
  retu 16:         for i in self.items: yield i
  exce 19:     async for i in AsyncIter([1]):
* line 20:         print(f"test1 {i}")
  retu 20:         print(f"test1 {i}")
  call 22: def test2():
  line 23:     for i in [1]:
  line 24:         print(f"test2 {i}")
  test2 1
  line 23:     for i in [1]:
> retu 23:     for i in [1]:

----------
components: Interpreter Core
keywords: 3.10regression
messages: 397396
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: async-for loops are traced incorrectly in Python 3.10
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Jul 13 10:48:39 2021
From: report at bugs.python.org (Jonathan Fine)
Date: Tue, 13 Jul 2021 14:48:39 +0000
Subject: [New-bugs-announce] [issue44623] help(open('/dev/zero').writelines)
 gives no help
Message-ID: <1626187719.66.0.592633008408.issue44623@roundup.psfhosted.org>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

On Linux
>>> help(open('/dev/zero').writelines)
gives
<built-in method writelines of _io.TextIOWrapper object at 0x7fed03d4e558>

However
https://docs.python.org/3/library/io.html#io.IOBase.writelines
gives

Write a list of lines to the stream. Line separators are not added, so it is usual for each of the lines provided to have a line separator at the end.

See also request that writelines support a line separator.
https://mail.python.org/archives/list/python-ideas at python.org/thread/A5FT7SVZBYAJJTIWQFTFUGNSKMVQNPVF/#A5FT7SVZBYAJJTIWQFTFUGNSKMVQNPVF

----------
assignee: docs at python
components: Documentation
messages: 397414
nosy: docs at python, jfine2358
priority: normal
severity: normal
status: open
title: help(open('/dev/zero').writelines) gives no help
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 13 11:04:11 2021
From: report at bugs.python.org (Paul Watson)
Date: Tue, 13 Jul 2021 15:04:11 +0000
Subject: [New-bugs-announce] [issue44624] Script name for venv PowerShell
 activate
Message-ID: <1626188651.64.0.496215753263.issue44624@roundup.psfhosted.org>


New submission from Paul Watson <paul.hermeneutic at gmail.com>:

In the venv .\Scripts directory. the name 'Activate.ps1' does not conform to the PowerShell prescribed Verb-Noun format.

How about using 'Initialize-Python.ps1' as the script name? Or, something else that does conform to PowerShell standard naming.

----------
components: Installation
messages: 397416
nosy: Paul Watson
priority: normal
severity: normal
status: open
title: Script name for venv PowerShell activate
type: enhancement

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

From report at bugs.python.org  Tue Jul 13 12:15:43 2021
From: report at bugs.python.org (Azat Ibrakov)
Date: Tue, 13 Jul 2021 16:15:43 +0000
Subject: [New-bugs-announce] [issue44625] Python C API version of
 `fractions` module
Message-ID: <1626192943.31.0.963042102585.issue44625@roundup.psfhosted.org>


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

Are there any plans for implementing `fractions` module in C (like  for `decimal` there is a https://github.com/python/cpython/blob/main/Modules/_decimal/_decimal.c module)?
I've implemented one myself (https://github.com/lycantropos/cfractions) and from benchmarks (available at https://stackoverflow.com/a/67821911/5997596) we can see that it can be faster that current pure Python implementation.

----------
messages: 397424
nosy: lycantropos
priority: normal
severity: normal
status: open
title: Python C API version of `fractions` module

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

From report at bugs.python.org  Tue Jul 13 14:23:06 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 13 Jul 2021 18:23:06 +0000
Subject: [New-bugs-announce] [issue44626] Incorrect tracing of nested
 if/if/for/yield
Message-ID: <1626200586.64.0.370955870537.issue44626@roundup.psfhosted.org>


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

In Python 3.10, this code is traced incorrectly. I don't know if there's a simpler format that would show the problem. This code is already simplified from https://github.com/nedbat/coveragepy/issues/1188.

------------------------------
import linecache, sys

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

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

def f(a, p, z):
    if p:
        print(f"{a=}")
        if a:
            if z:
                for x in [1,2]:
                    yield x
            else:
                for x in [1,2]:
                    yield x
    else:
        print("nope")

import itertools

for a, p, z in itertools.product([0, 1], repeat=3):
    list(f(a, p, z))
------------------------------------

Running this with 3.10.0b4 produces this output. The starred lines show a is false, but tracing then indicates a line which is not executed:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 13: def f(a, p, z):
  line 14:     if p:
  line 24:         print("nope")
  nope
  retu 24:         print("nope")
  call 13: def f(a, p, z):
  line 14:     if p:
  line 24:         print("nope")
  nope
  retu 24:         print("nope")
  call 13: def f(a, p, z):
  line 14:     if p:
  line 15:         print(f"{a=}")
  a=0
* line 16:         if a:
  line 22:                     yield x
  retu 22:                     yield x
  call 13: def f(a, p, z):
  line 14:     if p:
  line 15:         print(f"{a=}")
  a=0
* line 16:         if a:
  line 22:                     yield x
  retu 22:                     yield x
  call 13: def f(a, p, z):
  line 14:     if p:
  line 24:         print("nope")
  nope
  retu 24:         print("nope")
  call 13: def f(a, p, z):
  line 14:     if p:
  line 24:         print("nope")
  nope
  retu 24:         print("nope")
  call 13: def f(a, p, z):
  line 14:     if p:
  line 15:         print(f"{a=}")
  a=1
  line 16:         if a:
  line 17:             if z:
  line 21:                 for x in [1,2]:
  line 22:                     yield x
  retu 22:                     yield x
  call 22:                     yield x
  line 21:                 for x in [1,2]:
  line 22:                     yield x
  retu 22:                     yield x
  call 22:                     yield x
  line 21:                 for x in [1,2]:
  line 22:                     yield x
  retu 22:                     yield x
  call 13: def f(a, p, z):
  line 14:     if p:
  line 15:         print(f"{a=}")
  a=1
  line 16:         if a:
  line 17:             if z:
  line 18:                 for x in [1,2]:
  line 19:                     yield x
  retu 19:                     yield x
  call 19:                     yield x
  line 18:                 for x in [1,2]:
  line 19:                     yield x
  retu 19:                     yield x
  call 19:                     yield x
  line 18:                 for x in [1,2]:
  retu 18:                 for x in [1,2]:

----------
components: Interpreter Core
keywords: 3.10regression
messages: 397434
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Incorrect tracing of nested if/if/for/yield
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Jul 13 14:23:52 2021
From: report at bugs.python.org (jg)
Date: Tue, 13 Jul 2021 18:23:52 +0000
Subject: [New-bugs-announce] [issue44627] Python terminal cmd line recall
Message-ID: <1626200632.58.0.557312314472.issue44627@roundup.psfhosted.org>


New submission from jg <jggammon at hotmail.com>:

Command line recall in python terminal treats strings case insensitively.

Example:
Define a 'dummy' function that takes a string as input. If you run dummy twice with the same input string, but different cases, it only saves one.
>>> dummy("This is a test") # run this
>>> dummy("THIS IS A TEST") # run again w/ different string
Now if you try cmd recall, it only recalls the first.
I believe it should recall both.
Maybe it's treating one as a duplicate - erroneously?

----------
components: Windows
messages: 397435
nosy: jggammon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python terminal cmd line recall
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 13 14:43:14 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Tue, 13 Jul 2021 18:43:14 +0000
Subject: [New-bugs-announce] [issue44628] Remove the broken link for issue
 #445902 in unixcompiler.py (distutils)
Message-ID: <1626201794.58.0.874918644983.issue44628@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

There is a broken link in the docstring of the runtime_library_dir_option() method of the UnixCCompiler class.

See the broken link below:
http://sourceforge.net/tracker/index.php?func=detail&aid=445902&group_id=5470&atid=105470

And the link that is working for this same issue:
https://bugs.python.org/issue445902

I will send a PR removing the link, leaving without it, as there is already exists the issue ID in the docstring.

----------
components: Library (Lib)
messages: 397436
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Remove the broken link for issue #445902 in unixcompiler.py (distutils)
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 13 15:35:40 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Tue, 13 Jul 2021 19:35:40 +0000
Subject: [New-bugs-announce] [issue44629] Some files from distutils module
 are importing all exceptions unnecessarily
Message-ID: <1626204940.79.0.533758495697.issue44629@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

Some files from the distutils module are importing all the exceptions from the errors.py file unnecessarily, when in fact only a few of the Exception classes are used.

Could I open a PR by fixing the files that are making these unnecessary imports? Or is this problem in the same category as f-String refactorings?

----------
components: Library (Lib)
messages: 397441
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Some files from distutils module are importing all exceptions unnecessarily
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jul 13 17:49:13 2021
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 13 Jul 2021 21:49:13 +0000
Subject: [New-bugs-announce] [issue44630] Assertion failure in csv module
Message-ID: <1626212953.96.0.40256914813.issue44630@roundup.psfhosted.org>


New submission from Thomas Wouters <thomas at python.org>:

The csv module has some incorrect exception handling when dealing with dialect objects that are not csv.Dialect subclasses (or that otherwise raise errors when accessing the dialect attributes):

>>> csv.reader([], dialect=None)
python: ../../cpython/Objects/typeobject.c:3820: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.
Aborted

The problem is Modules/_csv.c tries to cater to dialects that lack the attributes it wants to access, but does so by leaving exceptions set between calls to PyObject_SetAttrString(). Since 3.7, that causes assertion failures. (I have a PR with a fix.)

----------
assignee: twouters
components: Extension Modules
messages: 397446
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
status: open
title: Assertion failure in csv module
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jul 13 18:04:27 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Tue, 13 Jul 2021 22:04:27 +0000
Subject: [New-bugs-announce] [issue44631] Refactoring the repr() of the
 _Environ class (os module)
Message-ID: <1626213867.27.0.881981550683.issue44631@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

Currently, the repr() code of the _Environ class does many things in a bunched way, making it difficult to read and difficult to determine the result returned by the method.

Therefore, I propose an adjustment in the code to make it more readable, as well as your test.

----------
components: Library (Lib)
messages: 397448
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Refactoring the repr() of the _Environ class (os module)
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 14 01:33:24 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Jul 2021 05:33:24 +0000
Subject: [New-bugs-announce] [issue44632] Union with TypeVar does not work
 as intended
Message-ID: <1626240804.32.0.699620622244.issue44632@roundup.psfhosted.org>


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

>>> import typing
>>> int | typing.T
int | ~T
>>> typing.T | int
typing.Union[~T, int]
>>> T2 = TypeVar('T2')
>>> int | T2
typing.Union[int, ~T2]
>>> T2 | int
typing.Union[~T2, int]

There is a support of TypeVar in type.__or__, but it does not work with user defined TypeVars, only with internal TypeVars defined in the typing module.

----------
components: Interpreter Core
messages: 397466
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Union with TypeVar does not work as intended
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jul 14 01:42:46 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Jul 2021 05:42:46 +0000
Subject: [New-bugs-announce] [issue44633] Indexing the union type can return
 NotImplemented
Message-ID: <1626241366.72.0.977588734187.issue44633@roundup.psfhosted.org>


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

>>> import typing
>>> (int | typing.T)[1]
NotImplemented

It is related to issue44632.

----------
components: Interpreter Core
messages: 397468
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Indexing the union type can return NotImplemented
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jul 14 06:51:23 2021
From: report at bugs.python.org (Pavel Moiseenko)
Date: Wed, 14 Jul 2021 10:51:23 +0000
Subject: [New-bugs-announce] [issue44634] Version is duplicated in name of
 app in list of installed apps
Message-ID: <1626259883.91.0.0747783095776.issue44634@roundup.psfhosted.org>


New submission from Pavel Moiseenko <rakleed at gmail.com>:

The version of the app is duplicated in the name of the app in the list of installed apps in "Settings - Apps - Apps & features" and "Control Panel - Programs - Programs and Features" in the version for Windows. Please remove the version number from the app name, as the version number is displayed next to the name in a separate field.

----------
components: Windows
files: 2021-07-14 13-49-41 Settings.png
messages: 397474
nosy: paul.moore, rakleed, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Version is duplicated in name of app in list of installed apps
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50147/2021-07-14 13-49-41 Settings.png

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

From report at bugs.python.org  Wed Jul 14 06:51:57 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Jul 2021 10:51:57 +0000
Subject: [New-bugs-announce] [issue44635] Convert None to NoneType in the
 union type constructor
Message-ID: <1626259917.98.0.435705646715.issue44635@roundup.psfhosted.org>


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

There is a difference between typing.Union and the builtin union type in representing None in __args__:

>>> import typing
>>> typing.Union[int, None].__args__
(<class 'int'>, <class 'NoneType'>)
>>> typing.Union[int, type(None)].__args__
(<class 'int'>, <class 'NoneType'>)
>>> (int | None).__args__
(<class 'int'>, None)
>>> (int | type(None)).__args__
(<class 'int'>, <class 'NoneType'>)

The former converts None to NoneType, the latter leaves it as is, and only performs conversion in __instancecheck__ and __subclasscheck__. In the discussion for issue44606 it was proposed to convert None to NoneType in the union type constructor to make more uniform with typing.Union and simplify __instancecheck__ and __subclasscheck__.

----------
components: Interpreter Core
messages: 397475
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert None to NoneType in the union type constructor
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jul 14 07:04:42 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Jul 2021 11:04:42 +0000
Subject: [New-bugs-announce] [issue44636] It is possible to create a 1-type
 union type
Message-ID: <1626260682.01.0.97762085111.issue44636@roundup.psfhosted.org>


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

typing.Union always collapsed to a simple type if it contains a single type.

>>> import typing
>>> typing.Union[int, typing.T][int]
<class 'int'>

But the builtin union type can contain a single type:

>>> (int | typing.T)[int]
int
>>> type((int | typing.T)[int])
<class 'types.Union'>

----------
components: Interpreter Core
messages: 397476
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: It is possible to create a 1-type union type
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jul 14 08:44:57 2021
From: report at bugs.python.org (Baptiste)
Date: Wed, 14 Jul 2021 12:44:57 +0000
Subject: [New-bugs-announce] [issue44637] Quoting issue on header Reply-To
Message-ID: <1626266697.4.0.946779337742.issue44637@roundup.psfhosted.org>


New submission from Baptiste <BaptisteVer.It at gmail.com>:

Hello,

When using as_string() on a Reply-To header like the following:
msg['Reply-To'] = '"foo Research, Inc. Foofoo BarBar on Summer Special Friday: 0.50 days (2021-02-31)" <catchall at foobar.exchange.com>'

The double quote disappear, which lead to wrong header value

See attached file for example

----------
components: email
files: Reply-To.py
messages: 397478
nosy: Abridbus, Julien Castiaux, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Quoting issue on header Reply-To
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50149/Reply-To.py

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

From report at bugs.python.org  Wed Jul 14 10:48:27 2021
From: report at bugs.python.org (Christian Steinmeyer)
Date: Wed, 14 Jul 2021 14:48:27 +0000
Subject: [New-bugs-announce] [issue44638] zipfile.ZipFile is closed when
 zipfile.Path is closed
Message-ID: <1626274107.84.0.867808492454.issue44638@roundup.psfhosted.org>


New submission from Christian Steinmeyer <christian.steinmeyer.1993 at gmail.com>:

When executing the code below with the attached zip file (or any other that has one or more files directly at root level), I get a "ValueError: seek of closed file". It seems, the zipfile handle being part of the `TestClass` instance is being closed, when the `zipfile.Path` is garbage collected, when it is no longer referenced. Since `zipfile.Path` even takes a `zipfile.Zipfile` as an argument, I don't think it is intended? It surprised me at least.


```
import zipfile


class TestClass:
    def __init__(self, path):
        self.zip_file = zipfile.ZipFile(path)

    def iter_dir(self):
        return [each.name for each in zipfile.Path(self.zip_file).iterdir()]

    def read(self, filename):
        with self.zip_file.open(filename) as file:
            print(file.read())

root = "zipfile.zip"
test = TestClass(root)
files = test.iter_dir()
test.read(files[0])
```

----------
components: Library (Lib)
files: zipfile.zip
messages: 397483
nosy: christian.steinmeyer
priority: normal
severity: normal
status: open
title: zipfile.ZipFile is closed when zipfile.Path is closed
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50150/zipfile.zip

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

From report at bugs.python.org  Wed Jul 14 12:53:08 2021
From: report at bugs.python.org (John M. Boger)
Date: Wed, 14 Jul 2021 16:53:08 +0000
Subject: [New-bugs-announce] [issue44639] [sqlite3] Confusing typo
 "transation"
Message-ID: <1626281588.36.0.0767264749964.issue44639@roundup.psfhosted.org>


New submission from John M. Boger <johnmboger at gmail.com>:

In the documentation for sqlite3.executescript() in python 3.9+, the pseudoword "transation" appears.  I am reasonably sure "transaction" is meant, although it could be "translation".

----------
assignee: docs at python
components: Documentation
messages: 397495
nosy: John M. Boger, docs at python
priority: normal
severity: normal
status: open
title: [sqlite3] Confusing typo "transation"
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Jul 14 13:40:20 2021
From: report at bugs.python.org (wyz23x2)
Date: Wed, 14 Jul 2021 17:40:20 +0000
Subject: [New-bugs-announce] [issue44640] Typos in error messages of
 isinstance() & issubclass()
Message-ID: <1626284420.22.0.865096690123.issue44640@roundup.psfhosted.org>


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

>>> isinstance(2, 1)
Traceback (most recent call last):
  ...
TypeError: isinstance() arg 2 must be a type, a tuple of types or a union
>>> issubclass(int, 1)
Traceback (most recent call last):
  ..
TypeError: issubclass() arg 2 must be a class, a tuple of classes, or a union.

1) It should be "an union", not "a union".
2) The punctuation marks aren't the same -- there's a comma before "or" in issubclass, but not isinstance(). And issubclass()'s ends with a period, which isn't the same with other builtins' messages.

----------
components: Interpreter Core
messages: 397499
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Typos in error messages of isinstance() & issubclass()
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Jul 14 20:48:25 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Thu, 15 Jul 2021 00:48:25 +0000
Subject: [New-bugs-announce] [issue44641] [sqlite3] Use vectorcall in
 pysqlite_collation_callback
Message-ID: <1626310105.09.0.713528558818.issue44641@roundup.psfhosted.org>


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

pysqlite_collation_callback() currently uses the variable argument function PyObject_CallFunctionObjArgs(). Suggesting micro-optimise this by using PyObject_Vectorcall instead.

----------
components: Extension Modules
messages: 397521
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] Use vectorcall in pysqlite_collation_callback
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul 15 03:58:18 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Jul 2021 07:58:18 +0000
Subject: [New-bugs-announce] [issue44642] Union of a type and the typing
 module function
Message-ID: <1626335898.92.0.441498587725.issue44642@roundup.psfhosted.org>


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

The union type accepts any function from the typing module:

>>> import typing
>>> int | typing.cast
int | typing.cast
>>> int | typing.get_type_hints
int | typing.get_type_hints

It is a consequence of too lenient check for the typing.NewType() result (which does not work at all with PR 9951).

----------
components: Interpreter Core
messages: 397528
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Union of a type and the typing module function
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Jul 15 04:30:05 2021
From: report at bugs.python.org (Patrick Reader)
Date: Thu, 15 Jul 2021 08:30:05 +0000
Subject: [New-bugs-announce] [issue44643] importing does not dispatch to
 __builtins__.__getitem__ to lookup __import__
Message-ID: <1626337805.62.0.910568399953.issue44643@roundup.psfhosted.org>


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

When a frame's __builtins__ is a subclass of dict with an overridden __getitem__ method, this overriden method is not used by the IMPORT_NAME instruction to lookup __import__ in the dictionary; it uses the lookup function of normal dictionaries (via _PyDict_GetItemIdWithError). This is contrary to the behaviour of the similar LOAD_BUILD_CLASS, as well as the typical name lookup semantics of LOAD_GLOBAL/LOAD_NAME, which all use PyDict_CheckExact for a "fast path" before defaulting to PyObject_GetItem, which is not the behaviour I expected.

Perhaps more seriously, if __builtins__ is not a dict at all, then it gets erroneously passed to some internal dict functions resulting in a mysterious SystemError ("Objects/dictobject.c:1440: bad argument to internal function") which, to me, indicates fragile behaviour that isn't supposed to happen.

Could this be changed, so that __builtins__ is used dynamically? I understand this is a highly specific use case and changing it would probably cause a bit of a slow-down in module importing so is perhaps not worth doing, but I've posted this issue to track it anyway.

I cannot find evidence that this behaviour has changed at all in recent history and it seems to be the same on the main branch as in 3.9.6.

Per a brief discussion with Brett Cannon on python-dev (https://mail.python.org/archives/list/python-dev at python.org/thread/ZQMF6XC76J4APJPB3X6PGATG6CV5NN44/), I have labelled this a feature request because it has never really been expected behaviour.

A short demo of these things is attached.

Links to relevant CPython code in v3.9.6:

IMPORT_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L5179

BUILD_CLASS: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2316

LOAD_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2488

LOAD_GLOBAL: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2546

----------
components: Interpreter Core
files: dict_lookup_demo.py
messages: 397531
nosy: brett.cannon, pxeger
priority: normal
severity: normal
status: open
title: importing does not dispatch to __builtins__.__getitem__ to lookup __import__
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50151/dict_lookup_demo.py

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

From report at bugs.python.org  Thu Jul 15 08:05:20 2021
From: report at bugs.python.org (origin400-p)
Date: Thu, 15 Jul 2021 12:05:20 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue44644=5D_Implement_?=
 =?utf-8?q?=E2=80=9CHappy_Eyeballs=E2=80=9D_algorithim_=28RFC_8503=29_in_s?=
 =?utf-8?q?ocket=2Ecreate=5Fconnection=28=29?=
Message-ID: <1626350720.92.0.994422492637.issue44644@roundup.psfhosted.org>


New submission from origin400-p <greg.kolanek at altova.com>:

While support for the so-called ?Happy Eyeballs? algorithim described in RFC 8503 was implemented for asyncio in Issue #33530, socket's create_connection function remains left without it causing suboptimal performance in broken dual-stack environments.

----------
components: Library (Lib)
messages: 397542
nosy: origin400-p
priority: normal
severity: normal
status: open
title: Implement ?Happy Eyeballs? algorithim (RFC 8503) in socket.create_connection()
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Thu Jul 15 09:26:07 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 15 Jul 2021 13:26:07 +0000
Subject: [New-bugs-announce] [issue44645] Python 3.10: Under some trivial
 circunstances, GIL not released
Message-ID: <1626355567.97.0.494557003743.issue44645@roundup.psfhosted.org>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

After https://github.com/python/cpython/pull/18334, a "while condition: pass" in a thread will preclude releasing the GIL, hanging the program with CPU at 100%.

Trivial to reproduce:

"""
#!/usr/bin/env python3.10

import threading
import time

def worker():
    while cont:
        pass

def main():
    global cont
    cont = True
    t = threading.Thread(target=worker)
    t.start()
    time.sleep(1)
    cont = False
    t.join()

if __name__ == '__main__':
    main()
"""

----------
keywords: 3.10regression
messages: 397549
nosy: Mark.Shannon, jcea, pablogsal
priority: release blocker
severity: normal
status: open
title: Python 3.10: Under some trivial circunstances, GIL not released
versions: Python 3.10

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

From report at bugs.python.org  Thu Jul 15 12:28:49 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Jul 2021 16:28:49 +0000
Subject: [New-bugs-announce] [issue44646] hash() of the unity type is not
 consistent with equality
Message-ID: <1626366529.09.0.940643989656.issue44646@roundup.psfhosted.org>


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

There is a rule: equal hashable objects should have the same hash. The unity type violates it.

>>> x = int | str
>>> y = str | int
>>> x == y
True
>>> hash(x) == hash(y)
False

And hashes of equal unity type and typing.Union are different too.

>>> import typing
>>> z = typing.Union[int, str]
>>> x == z
True
>>> hash(x) == hash(z)
False

There is also a problem with a single type (see issue44636).

----------
components: Interpreter Core
messages: 397567
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: hash() of the unity type is not consistent with equality
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Jul 15 13:50:20 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 15 Jul 2021 17:50:20 +0000
Subject: [New-bugs-announce] [issue44647] Non-ASCII characters in os.environ
 cause silent failures in test_httpservers
Message-ID: <1626371420.43.0.163040134112.issue44647@roundup.psfhosted.org>


New submission from ?ukasz Langa <lukasz at langa.pl>:

GH-23638 introduced a new test for Accept: headers in CGI HTTP servers. This test serializes all of `os.environ` on the server side.  For non-UTF8 locales this can fail for some Unicode characters found in environment variables.

This started failing this week on Azure Pipelines with their rollout of a new Windows 2019 image version that included a "BUILD_SOURCEVERSIONAUTHOR" env variable. For me specifically it includes a leading Unicode character so all my PRs started failing on Azure Pipelines Windows 2019 alone.

The result was truncated output from the CGI HTTP server, like:

======================================================================
FAIL: test_accept (test.test_httpservers.CGIHTTPServerTestCase) [OrderedDict([('Accept', 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8')])]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\1\s\lib\test\test_httpservers.py", line 860, in test_accept
    self.assertIn(expected.encode('ascii'), res.read())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: b"'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'" not found in b''


The root cause is that the CGI script in question (`cgi_file6` in test_httpservers.py) is crashing on server-side reaching the `print(repr(os.environ))` line. However, this exception isn't visible on the client side where the test is running. The only visible issue is truncated output.

I suggest adding ENSURE_UNICODE_WORKS=?ukasz to the testing env so that this never regresses.

----------
messages: 397572
nosy: lukasz.langa
priority: normal
severity: normal
status: open
title: Non-ASCII characters in os.environ cause silent failures in test_httpservers
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Jul 15 14:31:38 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Thu, 15 Jul 2021 18:31:38 +0000
Subject: [New-bugs-announce] [issue44648] Inspect.getsource raises wrong
 error on classes in interactive session
Message-ID: <1626373898.62.0.7619618577.issue44648@roundup.psfhosted.org>


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

[ins] In [63]: class A:pass

[ins] In [64]: import inspect

[ins] In [65]: inspect.getsource(A)

[snip]

/usr/local/Cellar/python at 3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/inspect.py in getfile(object)
    664             if getattr(module, '__file__', None):
    665                 return module.__file__
--> 666         raise TypeError('{!r} is a built-in class'.format(object))

The error is 'X is a built-in class', instead it should be OSError, source code is not available.

----------
messages: 397573
nosy: andrei.avk
priority: normal
severity: normal
status: open
title: Inspect.getsource raises wrong error on classes in interactive session
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul 15 15:06:03 2021
From: report at bugs.python.org (Christodoulos Tsoulloftas)
Date: Thu, 15 Jul 2021 19:06:03 +0000
Subject: [New-bugs-announce] [issue44649] dataclasses slots with init=False
 field raises AttributeException
Message-ID: <1626375963.06.0.364448585924.issue44649@roundup.psfhosted.org>


New submission from Christodoulos Tsoulloftas <chris at komposta.net>:

I am trying the new slots directive but I get an AttributeError when I try to access a field with init=False


>>> from dataclasses import dataclass, field
>>> 
>>> @dataclass(slots=True)
... class Example:
...     a: str
...     b: str = field(default="b", init=False)
... 
>>> obj = Example("a")
>>> obj.__slots__
('a', 'b')
>>> obj.
obj.a  obj.b  
>>> obj.a
'a'
>>> obj.b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: b. Did you mean: 'b'?
>>> 



? python --version
Python 3.10.0b4+

----------
components: Library (Lib)
messages: 397575
nosy: tefra
priority: normal
severity: normal
status: open
title: dataclasses slots with init=False field raises AttributeException
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Jul 15 16:39:48 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Thu, 15 Jul 2021 20:39:48 +0000
Subject: [New-bugs-announce] [issue44650] Move test_futures files* into a
 subdirectory of Lib/test
Message-ID: <1626381588.34.0.911825284448.issue44650@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

There are currently 6 files referring to __future__ tests, these are in the root directory Lib/test.

It would be interesting to move them to a directory called Lib/test/test_future.

This change could contribute to the organization of the tests that have already been discussed in other issues (e.g https://bugs.python.org/issue15907).

I wait for the ok to send the PR.

----------
messages: 397581
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Move test_futures files* into a subdirectory of Lib/test

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

From report at bugs.python.org  Fri Jul 16 01:11:26 2021
From: report at bugs.python.org (Steven Hsu)
Date: Fri, 16 Jul 2021 05:11:26 +0000
Subject: [New-bugs-announce] [issue44651] An unclear definition in
 Doc/glossary.rst
Message-ID: <1626412286.45.0.614621510926.issue44651@roundup.psfhosted.org>


New submission from Steven Hsu <hsuhaochun at gmail.com>:

In Doc/glossary.rst, the definition about "coercion" is as below:

"The implicit conversion of an instance of one type to another during an operation which involves two arguments of the same type."

However, in the example following this definition, it shows the arguments of "different" type in an adding operation, and one of them was converted to `float` for the operation.

Therefore, we should fix the definition of the coercion to as below:

"The implicit conversion of an instance of one type to another during an operation which involves two arguments of the different type."

Or am I realize this sentence wrong?
Thanks for review.

https://github.com/python/cpython/blob/main/Doc/glossary.rst

----------
assignee: docs at python
components: Documentation
messages: 397597
nosy: StevenHsuYL, docs at python
priority: normal
severity: normal
status: open
title: An unclear definition in Doc/glossary.rst
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Jul 16 07:07:49 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Jul 2021 11:07:49 +0000
Subject: [New-bugs-announce] [issue44652] Preserve natural order of args in
 the union type
Message-ID: <1626433669.69.0.820300846858.issue44652@roundup.psfhosted.org>


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

There are two issues related to the order of __args__ in typing.Union and the union type.

1. Indexing typing.Union preserves the order of arguments, but it is not always true when use the | operator.

>>> A = typing.NewType('A', str)
>>> typing.Union[typing.List[int], A]
typing.Union[typing.List[int], A]
>>> typing.Union[A, typing.List[int]]
typing.Union[A, typing.List[int]]
>>> typing.List[int] | A
typing.Union[typing.List[int], A]
>>> A | typing.List[int]
typing.Union[typing.List[int], A]

The cause is errors in __ror__ implementations.

2. There is a difference between deduplication algorithms for typing.Union and the union type.

>>> typing.Union[int, str, int]
typing.Union[int, str]
>>> int | str | int
str | int

It is not particularly important, because the order of __args__ mostly affects only representation. But it is better to be consistent, and it is easy to fix these tiny issues.

Note that it does not make the order of __args__ deterministic in all cases. Due to using caching for typing.Union it can be not always preserved if we merger typing.Union objects which differs only by order of arguments.

>>> import typing
>>> typing.Union[typing.Union[int, str], list]
typing.Union[int, str, list]
>>> typing.Union[typing.Union[str, int], list]
typing.Union[int, str, list]

----------
components: Interpreter Core, Library (Lib)
messages: 397612
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Preserve natural order of args in the union type
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jul 16 09:32:27 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Jul 2021 13:32:27 +0000
Subject: [New-bugs-announce] [issue44653] Parameter substitution in the
 union type does not work with typing.Union
Message-ID: <1626442347.74.0.420703742148.issue44653@roundup.psfhosted.org>


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

>>> import typing
>>> T = typing.TypeVar('T')
>>> (int | T)[typing.Union[str, list]]
NotImplemented

See also issue44633. But in this case the expected result is int | str | list or typing.Union[init, str, list].

----------
components: Interpreter Core
messages: 397624
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Parameter substitution in the union type does not work with typing.Union
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jul 16 11:24:47 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Jul 2021 15:24:47 +0000
Subject: [New-bugs-announce] [issue44654] Refactor and clean up the union
 type implementation
Message-ID: <1626449087.45.0.570024736737.issue44654@roundup.psfhosted.org>


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

I started reviewing and rewriting Objects/unionobject.c several weeks ago. Some discovered bugs were reported and fixed in separate issues: issue44606, issue44632, issue44635, issue44636, issue44646, issue44652. Before fixing the remaining bugs (issue44633, issue44642, issue44653) I want to merge some minor changes:

* Rename _Py_UnionType to _PyUnion_Type. It is how PyTypeObject instances are named.
* Add _PyUnion_Check() and _PyGenericAlias_Check(). It simplified the code.
* Do not expose _Py_Union(). It is only used locally.
* Move declarations of _Py_make_parameters and _Py_subs_parameters from genericaliasobject.h to internal/pycore_unionobject.h. They are for internal use only.
* Fix a possible leak in dedup_and_flatten_args().
* Significantly simplify union_richcompare(). The Python implementation can be used for comparing types.Union with typing.Union.
* Perform cheaper tests before more expensive tests in is_unionable().
* Optimize __module__ look up in is_typing_module() and support types without __module__.
* Fix outdated comments.
* Minor style fixes.
* Extract related tests to separate class.
* Make some tests more accurate: they should test for TypeError only specific operators, not constructors.

I am going to backport these changes to 3.10 to make backporting of future fixes easier.

----------
components: Interpreter Core
messages: 397635
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor and clean up the union type implementation
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jul 16 15:14:32 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Jul 2021 19:14:32 +0000
Subject: [New-bugs-announce] [issue44655] Confusing error with __slots__
Message-ID: <1626462872.04.0.450801873338.issue44655@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

This is related to issue 44649. This is the simplest non-dataclasses case I could come up with.

Given:

class Example:
    __slots__ = ('a', 'b')
    def __init__(self, a):
        self.a = a

obj = Example(42)
print(obj.b)

I get this in 3.10 and main:

Traceback (most recent call last):
  File "C:\home\eric\local\python\cpython\testdc.py", line 7, in <module>
    print(obj.b)
          ^^^^^
AttributeError: b. Did you mean: 'b'?


The error message is confusing.

3.8 gives:

Traceback (most recent call last):
  File "testdc.py", line 7, in <module>
    print(obj.b)
AttributeError: b

I don't have 3.9 around to test with.

Maybe don't print the "Did you mean" part if the suggestion is the same as the requested attribute?

The fact that the instance variable isn't initialized is the actual error in issue 44649, and I'll fix it there.

----------
components: Interpreter Core
messages: 397652
nosy: eric.smith, pablogsal
priority: normal
severity: normal
status: open
title: Confusing error with __slots__
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jul 16 15:26:39 2021
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 16 Jul 2021 19:26:39 +0000
Subject: [New-bugs-announce] [issue44656] Dangerous mismatch between
 MAXPATHLEN and MAX_PATH on Windows
Message-ID: <1626463599.7.0.822730075701.issue44656@roundup.psfhosted.org>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

In PC/getpathp.c CPython uses buffers with length MAXPATHLEN+1, which is 257 on Windows[1]. On Windows 7, where PathCch* functions are not available, CPython <= 3.8 fallbacks to PathCombineW()/PathCanonicalizeW()[2]. Those functions assume that the destination buffer has room for MAX_PATH (260) characters. This creates a dangerous setup: for example, gotlandmark()[3] can overflow the destination if `filename` is long enough, and `filename` can be user-controlled.

I couldn't devise a simple way to trigger a buffer overflow in a default Python installation, though it is possible if one, for example, makes sure that the landmark file ("lib\os.py") can't be found in the default locations and then supplies their own, long enough paths via e.g. PYTHONPATH environment variable which eventually end up in gotlandmark(). Even when such buffer overflow is triggered on my machine, I couldn't notice any change in behavior, probably because 3 bytes is small enough to not overwrite anything important.

However, I'm not comfortable with this. Could we just raise MAXPATHLEN from 256 to 260 on Windows to avoid such kind of issues for sure?

Please also note that while the issue described above affects only Python <= 3.8 on Windows 7, I think it would make sense to increase MAXPATHLEN in newer versions too to avoid any similar situations in the future (i.e. if two pieces of code interact and one of them uses MAX_PATH while another uses MAXPATHLEN).

[1] https://github.com/python/cpython/blob/0389426fa4af4dfc8b1d7f3f291932d928392d8b/Include/osdefs.h#L13
[2] https://github.com/python/cpython/blob/0389426fa4af4dfc8b1d7f3f291932d928392d8b/PC/getpathp.c#L278
[3] https://github.com/python/cpython/blob/0389426fa4af4dfc8b1d7f3f291932d928392d8b/PC/getpathp.c#L333

----------
components: Windows
messages: 397655
nosy: izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Dangerous mismatch between MAXPATHLEN and MAX_PATH on Windows
type: security
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Jul 16 15:43:58 2021
From: report at bugs.python.org (Sam Gross)
Date: Fri, 16 Jul 2021 19:43:58 +0000
Subject: [New-bugs-announce] [issue44657] instancemethod_call should use
 PyInstanceMethod_GET_FUNCTION macro
Message-ID: <1626464638.16.0.397539197321.issue44657@roundup.psfhosted.org>


New submission from Sam Gross <colesbury at gmail.com>:

The instancemethod_call function should use the PyInstanceMethod_GET_FUNCTION macro instead of the PyMethod_GET_FUNCTION macro. The current code is incorrect, but still works okay (doesn't crash)  because PyInstanceMethodObject.func is at the same offset as PyMethodObject.im_func.

https://github.com/python/cpython/blob/c90c591e5158ab7b531dcd6e2a5f00bc70ba7637/Objects/classobject.c#L465

----------
components: Interpreter Core
messages: 397660
nosy: colesbury
priority: normal
severity: normal
status: open
title: instancemethod_call should use PyInstanceMethod_GET_FUNCTION macro
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jul 16 16:32:00 2021
From: report at bugs.python.org (Jack DeVries)
Date: Fri, 16 Jul 2021 20:32:00 +0000
Subject: [New-bugs-announce] [issue44658] No ValueError for duplicate key
 value in mapping patern when lengths do not match
Message-ID: <1626467520.14.0.17639663764.issue44658@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

Consider the following code:

class A:
    a = 'a'

# runs without error
match {'a': 1}:
    case {'a': 1, A.a: 1}:
        pass

# raises ValueError
match {'a': 1, 'b': 1}:
    case {'a': 1, A.a: 1}:
        pass

In both cases, the mapping pattern is the same (and both are not valid due to duplicate key values). However, the pattern is only evaluated in the second case. This is because a key-length optimization provides a shortcut around pattern evaluation. The docs gives users a hint that things like this might happen, which is a good thing:

> Users should generally never rely on a pattern being evaluated. Depending on > implementation, the interpreter may cache values or use other optimizations > which skip repeated evaluations. 

> https://docs.python.org/3.10/reference/compound_stmts.html#overview

However, I can't help but think that these ergonomics are strange. Consider if some other code is mutating the value of `A.a`. This could create some very strange and flaky bugs where the state of `A.a` can change and make the pattern invalid, but nonetheless not cause an exception until much later, or not at all.

There is mapping pattern validation code in the `match_keys` function in ceval.c. I haven't looked, but I assume there is some other runtime validation for other match case types. I propose factoring Exception-raising validation into a separate procedure that is called before any optimization jumps occur.

This trades speed for consistent behavior, and I'm interested to hear what others think!

----------
components: Interpreter Core
messages: 397662
nosy: jack__d
priority: normal
severity: normal
status: open
title: No ValueError for duplicate key value in mapping patern when lengths do not match
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jul 16 23:42:04 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 17 Jul 2021 03:42:04 +0000
Subject: [New-bugs-announce] [issue44659] Remove Ivan from list of,
 typing experts
Message-ID: <1626493324.95.0.344055297429.issue44659@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

There is a list somewhere in bpo or GH that automatically adds Ivan to all bugs or reviews involving typing. He is no longer active. Can we remove him from those lists? And maybe add Ken Jin, who has built up a lot of expertise  in this area.

----------
messages: 397688
nosy: gvanrossum, kj, levkivskyi, lukasz.langa
priority: normal
severity: normal
status: open
title: Remove Ivan from list of,typing experts

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

From report at bugs.python.org  Fri Jul 16 23:52:51 2021
From: report at bugs.python.org (Francis Johnson)
Date: Sat, 17 Jul 2021 03:52:51 +0000
Subject: [New-bugs-announce] [issue44660] email.feedparser Module Lacks
 Support for Section 3.5 of RFC 6532: message/global Emails with
 non-identity Content-Transfer-Encodings
Message-ID: <1626493971.02.0.0360385916287.issue44660@roundup.psfhosted.org>


New submission from Francis Johnson <business at francisjohnson.org>:

Note that I have created a fix for this and am working through the Python Developer?s Guide to propose it.

----------
components: email
messages: 397693
nosy: barry, f18a14c09s, r.david.murray
priority: normal
severity: normal
status: open
title: email.feedparser Module Lacks Support for Section 3.5 of RFC 6532: message/global Emails with non-identity Content-Transfer-Encodings
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Jul 17 01:19:43 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 17 Jul 2021 05:19:43 +0000
Subject: [New-bugs-announce] [issue44661] Update property_descr_set to use
 vectorcall if possible.
Message-ID: <1626499183.47.0.424501329703.issue44661@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

It shows a consistent 1-2% performance improvement.

Mean +- std dev: [property_base] 40.6 ns +- 0.6 ns -> [property_vectorcall] 40.0 ns +- 0.7 ns: 1.01x faster

----------
components: Interpreter Core
files: bench_property.py
messages: 397701
nosy: corona10, erlendaasland, kj, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Update property_descr_set to use vectorcall if possible.
type: performance
versions: Python 3.11
Added file: https://bugs.python.org/file50154/bench_property.py

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

From report at bugs.python.org  Sat Jul 17 06:33:33 2021
From: report at bugs.python.org (Yurii Karabas)
Date: Sat, 17 Jul 2021 10:33:33 +0000
Subject: [New-bugs-announce] [issue44662] Add ability to serialise and
 annotated types.Union
Message-ID: <1626518013.71.0.944961363748.issue44662@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

It was discussed at https://bugs.python.org/issue44490

----------
messages: 397720
nosy: uriyyo
priority: normal
severity: normal
status: open
title: Add ability to serialise and annotated types.Union
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Jul 17 17:20:17 2021
From: report at bugs.python.org (Gabriel Costa)
Date: Sat, 17 Jul 2021 21:20:17 +0000
Subject: [New-bugs-announce] [issue44663] Possible bug in datetime utc
Message-ID: <1626556817.96.0.446467622076.issue44663@roundup.psfhosted.org>


New submission from Gabriel Costa <gabrielsantos.ghsc at gmail.com>:

>>> datetime.now(timezone.utc).timestamp()
1626556067.054988
>>> datetime.utcnow().timestamp()
1626566875.174921

Should there be a difference between the two modes?

----------
components: C API
messages: 397733
nosy: gabhcosta
priority: normal
severity: normal
status: open
title: Possible bug in datetime utc
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Jul 17 18:40:19 2021
From: report at bugs.python.org (Dan Snider)
Date: Sat, 17 Jul 2021 22:40:19 +0000
Subject: [New-bugs-announce] [issue44664] builtins.chr and the 'c' format
 flag raise different errors
Message-ID: <1626561619.16.0.845044555261.issue44664@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

chr (or anything else which calls `PyUnicode_FromOrdinal`) raises ValueError if its argument falls outside the range of valid Unicode code points, while `PyUnicode_FromFormat` raises OverflowError. Shouldn't the latter raise ValueError as well?

----------
messages: 397735
nosy: bup
priority: normal
severity: normal
status: open
title: builtins.chr and the 'c' format flag raise different errors
type: behavior

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

From report at bugs.python.org  Sun Jul 18 02:01:26 2021
From: report at bugs.python.org (Vincent Bernat)
Date: Sun, 18 Jul 2021 06:01:26 +0000
Subject: [New-bugs-announce] [issue44665] asyncio.create_task()
 documentation should mention user needs to keep reference to the task
Message-ID: <1626588086.28.0.802457585502.issue44665@roundup.psfhosted.org>


New submission from Vincent Bernat <python at vincent.bernat.ch>:

asyncio will only keep weak references to alive tasks (in `_all_tasks`). If a user does not keep a reference to a task and the task is not currently executing or sleeping, the user may get "Task was destroyed but it is pending!".

I would suggest adding the following paragraph to `create_task()` documentation:

Python only keeps weak references to the scheduled tasks. To avoid the task being destroyed by the garbage collector while still pending, a reference to it should be kept until the task is done.

And maybe an example in case a user wants something "fire and forget"?

```python
running_tasks = set()
# [...]
task = asyncio.create_task(some_background_function())
running_tasks.add(task)
task.add_done_callback(lambda t: running_tasks.remove(t))
```

The same applies to ensure_future as it now uses create_task, so maybe a "See create_task()".

----------
assignee: docs at python
components: Documentation
messages: 397741
nosy: bernat, docs at python
priority: normal
severity: normal
status: open
title: asyncio.create_task() documentation should mention user needs to keep reference to the task
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Jul 18 04:57:11 2021
From: report at bugs.python.org (=?utf-8?q?Stefan_H=C3=B6lzl?=)
Date: Sun, 18 Jul 2021 08:57:11 +0000
Subject: [New-bugs-announce] [issue44666] compileall.compile_file fails when
 sys.stdout is redirected to StringIO
Message-ID: <1626598631.59.0.122481145082.issue44666@roundup.psfhosted.org>


New submission from Stefan H?lzl <stefanh+pythonbugs at posteo.de>:

compile_files tries to escape non-printable characters in error messages by using sys.stdout.encoding
https://github.com/python/cpython/blob/main/Lib/compileall.py#L256

when using contextlib.redirect_stdout to redirect stdout to io.StringIO as explained in the documentation
https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout

compile_file fails, because io.StringIO has encoding set to None.

see the attached file to reproduce the issue

----------
components: Library (Lib)
files: compile_file_bug.py
messages: 397743
nosy: stefanhoelzl
priority: normal
severity: normal
status: open
title: compileall.compile_file fails when sys.stdout is redirected to StringIO
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50156/compile_file_bug.py

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

From report at bugs.python.org  Sun Jul 18 09:50:13 2021
From: report at bugs.python.org (Matthieu Dartiailh)
Date: Sun, 18 Jul 2021 13:50:13 +0000
Subject: [New-bugs-announce] [issue44667] tokenize.py emits spurious NEWLINE
 if file ends on a comment without a newline
Message-ID: <1626616213.56.0.119364692181.issue44667@roundup.psfhosted.org>


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

Using tokenize.py to tokenize the attached file yields:
0,0-0,0:            ENCODING       'utf-8'
1,0-1,2:            NAME           'if'
1,3-1,4:            NAME           'a'
1,4-1,5:            OP             ':'
1,5-1,7:            NEWLINE        '\r\n'
2,0-2,4:            INDENT         '    '
2,4-2,5:            NAME           'b'
2,6-2,7:            OP             '='
2,8-2,9:            NUMBER         '1'
2,9-2,11:           NEWLINE        '\r\n'
3,0-3,2:            NL             '\r\n'
4,0-4,6:            COMMENT        '# test'
4,6-4,6:            NL             ''
4,6-4,7:            NEWLINE        ''
5,0-5,0:            DEDENT         ''
5,0-5,0:            ENDMARKER      ''

This output is wrong in that it adds 2 newlines one as a NL which is a correct and one as a NEWLINE which is not since there is no preceding code.

If a new line is added at the end of the file, one gets:

0,0-0,0:            ENCODING       'utf-8'
1,0-1,2:            NAME           'if'
1,3-1,4:            NAME           'a'
1,4-1,5:            OP             ':'
1,5-1,7:            NEWLINE        '\r\n'
2,0-2,4:            INDENT         '    '
2,4-2,5:            NAME           'b'
2,6-2,7:            OP             '='
2,8-2,9:            NUMBER         '1'
2,9-2,11:           NEWLINE        '\r\n'
3,0-3,2:            NL             '\r\n'
4,0-4,6:            COMMENT        '# test'
4,6-4,8:            NL             '\r\n'
5,0-5,0:            DEDENT         ''
5,0-5,0:            ENDMARKER      ''

Similarly if code is added before the comment, a single NEWLINE is generated (with no text since it is fake).

The extra NEWLINE found when tokenizing the attached file can cause issue when parsing the file. It was found in https://github.com/we-like-parsers/pegen/pull/11#issuecomment-881926767 where a pure python parser based on pegen is being built. The extra NEWLINE is an issue since the grammar does not accept NEWLINE at the end of a block and cause parsing to fail using the same rules as the python grammar while the cpython parser can handle this file without any issue.

I believe this issue stems from https://github.com/python/cpython/blob/3.9/Lib/tokenize.py#L605 where the check does not account for a last line limited to comments. Adding a check to determine if the line starts with a # should be sufficient to avoid emitting the extra NEWLINE.

----------
components: Library (Lib)
files: no_newline_at_end_of_file_with_comment.py
messages: 397750
nosy: mdartiailh
priority: normal
severity: normal
status: open
title: tokenize.py emits spurious NEWLINE if file ends on a comment without a newline
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50157/no_newline_at_end_of_file_with_comment.py

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

From report at bugs.python.org  Sun Jul 18 13:21:30 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Jul 2021 17:21:30 +0000
Subject: [New-bugs-announce] [issue44668] More differences in instance and
 subclass checks between typing.Union and types.Union
Message-ID: <1626628890.53.0.612385746945.issue44668@roundup.psfhosted.org>


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

1. Checks for types.Union ignore any non-type args. Checks for typing.Union require fail on first checked non-type (but it can short circuit).

>>> import typing
>>> T = typing.TypeVar('T')
>>> issubclass(int, int | T | str)
True
>>> issubclass(int, str | T | int)
True
>>> issubclass(int, typing.Union[int, T, str])
True
>>> issubclass(int, typing.Union[str, T, int])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1208, in __subclasscheck__
    if issubclass(cls, arg):
       ^^^^^^^^^^^^^^^^^^^^
TypeError: issubclass() arg 2 must be a class, a tuple of classes, or a union.
>>> isinstance(1, int | T | str)
True
>>> isinstance(1, str | T | int)
True
>>> isinstance(1, typing.Union[int, T, str])
True
>>> isinstance(1, typing.Union[str, T, int])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1204, in __instancecheck__
    return self.__subclasscheck__(type(obj))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1208, in __subclasscheck__
    if issubclass(cls, arg):
       ^^^^^^^^^^^^^^^^^^^^
TypeError: issubclass() arg 2 must be a class, a tuple of classes, or a union.

2. __instancecheck__ of typing.Union uses __subclasscheck__ of args instead of __instancecheck__. In normal cases the result should be the same, but there should be a reason of having two different special methods.

----------
messages: 397757
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: More differences in instance and subclass checks between typing.Union and types.Union

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

From report at bugs.python.org  Sun Jul 18 16:25:01 2021
From: report at bugs.python.org (Michal D.)
Date: Sun, 18 Jul 2021 20:25:01 +0000
Subject: [New-bugs-announce] [issue44669] TypeError: 'type' object is not
 subscriptable
Message-ID: <1626639901.47.0.668651753174.issue44669@roundup.psfhosted.org>


New submission from Michal D. <michal.dziczkowski at gmail.com>:

While attempting to run an application with was working before I had updated Python to the version 3.9, I had recieved following error message:


`
Fatal Python error: init_import_size: Failed to import the site module
Python runtime state: initialized

Traceback (most recent call last):

  File "/usr/lib/python3.9/site.py", line 79, in <module>
    import os
  File "/usr/lib/python3.9/os.py", line 29, in <module>
    from _collections_abc import _check_methods
  File "/usr/lib/python3.9/_collections_abc.py", line 12, in <module>
    GenericAlias = type(list[int])

TypeError: 'type' object is not subscriptable


`

Any workarounds for this ?


OS: Debian 10 (64-bit)

----------
messages: 397758
nosy: michal.dziczkowski
priority: normal
severity: normal
status: open
title: TypeError: 'type' object is not subscriptable
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Jul 18 17:27:05 2021
From: report at bugs.python.org (Toby Spooner)
Date: Sun, 18 Jul 2021 21:27:05 +0000
Subject: [New-bugs-announce] [issue44670] bug on showing tuple on console
Message-ID: <1626643625.31.0.374965522349.issue44670@roundup.psfhosted.org>


New submission from Toby Spooner <kwutge at gmail.com>:

def func(a,b,c , *args , **kwargs):
    print(a)
    print(args)
    print(kwargs)

func(2,3,4,5,Carlson=240,Shehroz="maladiss")

# print(args) showing (5,). NEED TO FIX. python 3.9.6

----------
components: Interpreter Core
files: abc.png
messages: 397759
nosy: kwutge
priority: normal
severity: normal
status: open
title: bug on showing tuple on console
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50158/abc.png

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

From report at bugs.python.org  Sun Jul 18 17:33:48 2021
From: report at bugs.python.org (Jarrod Price)
Date: Sun, 18 Jul 2021 21:33:48 +0000
Subject: [New-bugs-announce] [issue44671] Create a built-in yaml module
Message-ID: <1626644028.22.0.677421965462.issue44671@roundup.psfhosted.org>


New submission from Jarrod Price <jarpri08 at gmail.com>:

Would it be possible for someone to take the time to create a built-in yaml module based on the current spec (v1.2) ?

https://yaml.org/spec/1.2/spec.html

Just like how we can do `import json`, there is currently no `import yaml`.

I myself (and I assume others too) would much prefer to be able to create/save/load/edit yaml as if it were a dictionary.

I am one of those guys that don?t really like to install external modules and I much prefer to just use the batteries included modules.

----------
messages: 397761
nosy: jarpri08
priority: normal
severity: normal
status: open
title: Create a built-in yaml module
type: enhancement

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

From report at bugs.python.org  Mon Jul 19 08:03:13 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 19 Jul 2021 12:03:13 +0000
Subject: [New-bugs-announce] [issue44672] Final "pass" is traced incorrectly
 in 3.9 (and before)
Message-ID: <1626696193.12.0.565896913641.issue44672@roundup.psfhosted.org>


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

A simple function with a last "pass" statement gets traced incorrectly, attributing the return to the pass instead of the actual last statement executed:

--- 8< --------------------------
import linecache, sys

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

def wrong_loop(x):
    if x:
        if x:
            print(4)
    else:
        pass

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

wrong_loop(8)
----------------------------------

On 3.9 and before, this produces:

3.9.5 (default, May  5 2021, 06:50:43)
[Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def wrong_loop(x):
line 11:     if x:
line 12:         if x:
line 13:             print(4)
4
line 15:         pass
retu 15:         pass

Partly I'm writing this issue to record the problem, but partly to get a decision: will there be fixes made to 3.9 (or before) for issues like this?

----------
components: Interpreter Core
messages: 397791
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Final "pass" is traced incorrectly in 3.9 (and before)
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul 19 09:42:09 2021
From: report at bugs.python.org (emve)
Date: Mon, 19 Jul 2021 13:42:09 +0000
Subject: [New-bugs-announce] [issue44673] Embedded Python - local
 directories in pythonXX._pth
Message-ID: <1626702129.3.0.0436089797565.issue44673@roundup.psfhosted.org>


New submission from emve <michal at vanka.net>:

When I add mylib to python39._pth, Python treats
it relatively to c:\Python3 (where my embedded python resides).

>>> import sys
>>> print('\n'.join(sys.path))
c:\python3\python39.zip
c:\python3
c:\python3\lib
c:\python3\mylib
c:\python3\lib\site-packages
>>>

However, my mylib directory is in my current project directory,
which is obviously not under c:\Python3

I know that the solution is to enter full path to mylib into python39._pth, but it is quite unconvenient as I have multiple projects, each with its own local modules in mylib directory.

Is there a way to simply add only one mylib
entry into python39._pth?

----------
messages: 397797
nosy: emve
priority: normal
severity: normal
status: open
title: Embedded Python - local directories in pythonXX._pth
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Jul 19 10:06:32 2021
From: report at bugs.python.org (Gianni Mariani)
Date: Mon, 19 Jul 2021 14:06:32 +0000
Subject: [New-bugs-announce] [issue44674] dataclasses should allow
 frozendict default value
Message-ID: <1626703592.29.0.0154308260517.issue44674@roundup.psfhosted.org>


New submission from Gianni Mariani <gianni at mariani.ws>:

Using a frozendict as a default value should not cause an error in dataclasses. The check for mutability is:

   isinstance(f.default, (list, dict, set))

It appears frozendict has been changed to have a dict base class and it now raises an exception.

There should be a way to indicate object mutability as the purpose of the isinstance(f.default, (list, dict, set)) check is for mutable default values.

Using default_factory to work around this issue is cumbersome.

----------
components: Library (Lib)
messages: 397799
nosy: gianni
priority: normal
severity: normal
status: open
title: dataclasses should allow frozendict default value
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Mon Jul 19 11:49:31 2021
From: report at bugs.python.org (Jeremy)
Date: Mon, 19 Jul 2021 15:49:31 +0000
Subject: [New-bugs-announce] [issue44675] Cross-platform issues with private
 methods and multiprocessing
Message-ID: <1626709771.89.0.929780396905.issue44675@roundup.psfhosted.org>


New submission from Jeremy <jeremy.westhead456 at gmail.com>:

While writing a program using the multiprocessing library I stumbled upon what appears to be a bug with how different platforms deal with private methods.

When a class has a private method which is the target for a multiprocessing process, this name is correctly resolved on Linux (20.04.1-Ubuntu running Python 3.8.10) but fails to be resolved correctly on MacOS (Python 3.8.2 and 3.8.8) or Windows 10 (Python 3.9.6).


import multiprocessing

class Test(object):
    def __init__(self):
        self.a = 1
        self._b = 2
        self.__c = 3
        self.run1()
        self.run2()
    def _test1(self, conn):
        conn.send(self._b)
    def __test2(self, conn):
        conn.send(self.__c)
    def run1(self):
        print("Running self._test1()")
        parent, child = multiprocessing.Pipe()
        process = multiprocessing.Process(target=self._test1, args=(child, ))
        process.start()
        print(parent.recv())
        process.join()
    def run2(self):
        print("Running self.__test2()")
        parent, child = multiprocessing.Pipe()
        process = multiprocessing.Process(target=self.__test2, args=(child, ))
        process.start()
        print(parent.recv())
        process.join()

if __name__ == "__main__":
    t = Test()


On Linux, this has the intended behavior of printing:
Running self._test1()
2
Running self.__test2()
3

However, on Windows 10, this results in an Exception being raised:
Running self._test1()
2
Running self.__test2()
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\<USER>\AppData\Local\Programs\Python\Python39\lib\multiprocessing\spawn.py", line 116, in spawn_main
    exitcode = _main(fd, parent_sentinel)
  File "C:\Users\<USER>\AppData\Local\Programs\Python\Python39\lib\multiprocessing\spawn.py", line 126, in _main
    self = reduction.pickle.load(from_parent)
AttributeError: 'Test' object has no attribute '__test2'

A similar exception is also raised on MacOS for this code.


It would therefore appear that there is different behavior for resolving class attributes starting with `__` on different platforms (at least within multiprocessing). It is my understanding that because multiprocessing.Process is called within the class, the private method should be within scope and so should resolve correctly.
I'm aware that Python doesn't have strict private methods, and instead renames them (Test.__test2 becomes Test._Test__test2) - explaining why on Windows it cannot find the attribute with that name. 

My question really is, which platform is correct here, and is the inconsistency intentional? I'd suggest Linux is most correct here as the process is spawned from within the object so the method should be in scope, but either way, the inconsistency between platforms may cause some unintended issues.

----------
components: Library (Lib), Windows, macOS
messages: 397810
nosy: ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, ymerej, zach.ware
priority: normal
severity: normal
status: open
title: Cross-platform issues with private methods and multiprocessing
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul 19 12:20:13 2021
From: report at bugs.python.org (Yurii Karabas)
Date: Mon, 19 Jul 2021 16:20:13 +0000
Subject: [New-bugs-announce] [issue44676] Add ability to serialise
 types.Union
Message-ID: <1626711613.61.0.665333814569.issue44676@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

It was discussed at https://bugs.python.org/issue44490

----------
messages: 397814
nosy: uriyyo
priority: normal
severity: normal
status: open
title: Add ability to serialise types.Union

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

From report at bugs.python.org  Mon Jul 19 13:40:33 2021
From: report at bugs.python.org (Piotr Tokarski)
Date: Mon, 19 Jul 2021 17:40:33 +0000
Subject: [New-bugs-announce] [issue44677] CSV sniffing falsely detects space
 as a delimiter
Message-ID: <1626716433.69.0.308565611704.issue44677@roundup.psfhosted.org>


New submission from Piotr Tokarski <pt12lol at gmail.com>:

Let's consider the following CSV content: "a|b\nc| 'd\ne|' f". The real delimiter in this case is '|' character while ' ' is sniffed. Find verbose example attached.

Problem lays in csv.py file in the following code:

```
        matches = []
        for restr in (r'(?P<delim>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?P=delim)', # ,".*?",
                      r'(?:^|\n)(?P<quote>["\']).*?(?P=quote)(?P<delim>[^\w\n"\'])(?P<space> ?)',   #  ".*?",
                      r'(?P<delim>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?:$|\n)',   # ,".*?"
                      r'(?:^|\n)(?P<quote>["\']).*?(?P=quote)(?:$|\n)'):                            #  ".*?" (no delim, no space)
            regexp = re.compile(restr, re.DOTALL | re.MULTILINE)
            matches = regexp.findall(data)
            if matches:
                break
```

What makes matches non-empty and farther processing happens with delimiter falsely set to ' '.

----------
components: Library (Lib)
messages: 397821
nosy: pt12lol
priority: normal
severity: normal
status: open
title: CSV sniffing falsely detects space as a delimiter
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Jul 19 14:32:54 2021
From: report at bugs.python.org (Idan Moral)
Date: Mon, 19 Jul 2021 18:32:54 +0000
Subject: [New-bugs-announce] [issue44678] Seperate error message for
 discontinuous padding in binascii.a2b_base64 strict mode
Message-ID: <1626719574.0.0.378248242955.issue44678@roundup.psfhosted.org>


New submission from Idan Moral <idan22moral at gmail.com>:

This is a follow-up PR to #24402.

It should address @gpshead's last comment on the subject:
https://github.com/python/cpython/pull/24402#issuecomment-882699002

Original issue: https://bugs.python.org/issue43086
Original PR: https://github.com/python/cpython/pull/24402

----------
components: Extension Modules, Library (Lib)
messages: 397831
nosy: gregory.p.smith, idan22moral
priority: normal
severity: normal
status: open
title: Seperate error message for discontinuous padding in binascii.a2b_base64 strict mode
versions: Python 3.11

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

From report at bugs.python.org  Mon Jul 19 17:15:28 2021
From: report at bugs.python.org (Andrii Haidai)
Date: Mon, 19 Jul 2021 21:15:28 +0000
Subject: [New-bugs-announce] [issue44679] unittest.mock.sentinel
 documentation typo
Message-ID: <1626729328.44.0.624843688761.issue44679@roundup.psfhosted.org>


New submission from Andrii Haidai <gaydayav at gmail.com>:

here: 
    https://docs.python.org/3.3/library/unittest.mock.html#sentinel
in code example block in last command line
    >>> sentinel.some_object
according to the above 26.4.5.1 article context it looks like the other commad is expected:
    >>> result
To ensure that at the end "result" equals sentinel.some_object we probably should print the "result" value to check, not the "sentinel.some_object" itself.

----------
assignee: docs at python
components: Documentation
messages: 397839
nosy: docs at python, gaydayav
priority: normal
severity: normal
status: open
title: unittest.mock.sentinel documentation typo
versions: Python 3.6

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

From report at bugs.python.org  Mon Jul 19 17:23:17 2021
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 19 Jul 2021 21:23:17 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue44680=5D_Reference_cycles_?=
 =?utf-8?q?from_a_WeakKeyDictionary_value_to_its_key_aren=E2=80=99t_collec?=
 =?utf-8?q?ted?=
Message-ID: <1626729797.43.0.421968257502.issue44680@roundup.psfhosted.org>


New submission from Anders Kaseorg <andersk at mit.edu>:

Because WeakKeyDictionary unconditionally maintains strong references to its values, the garbage collector fails to collect a reference cycle from a WeakKeyDictionary value to its key.  For example, the following program unexpectedly leaks memory:

from weakref import WeakKeyDictionary
class C: pass
d = WeakKeyDictionary()
while True:
    c = C()
    d[c] = [c]

I would expect a WeakKeyDictionary value to be marked live _if_ its key is marked live, not unconditionally.  This could be implemented with garbage collector support for ephemerons (https://www.researchgate.net/publication/221320677_Ephemerons_A_New_Finalization_Mechanism).

To motivate this issue, a typical use of WeakKeyDictionary is as a hygienic replacement for patching extra properties into third-party objects:

# before:
obj._extra_state = ExtraState(obj)
# after:
extra_states = WeakKeyDictionary()
extra_states[o] = ExtraState(obj)

However, such a conversion will introduce this memory leak if ExtraState(obj) has any transitive references to obj.

This leak does not occur in JavaScript:

class C {}
const d = new WeakMap();
while (true) {
  const c = new C();
  d[c] = [c];
}

----------
components: Library (Lib)
messages: 397841
nosy: andersk
priority: normal
severity: normal
status: open
title: Reference cycles from a WeakKeyDictionary value to its key aren?t collected
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Mon Jul 19 23:04:39 2021
From: report at bugs.python.org (Thereisfood)
Date: Tue, 20 Jul 2021 03:04:39 +0000
Subject: [New-bugs-announce] [issue44681] time.sleep(0.001) not working
 properly
Message-ID: <1626750279.58.0.537841916177.issue44681@roundup.psfhosted.org>


New submission from Thereisfood <therenoisfood at gmail.com>:

time.sleep(0.001) sleeps for 0.014 - 0.016 instead of 0.001.

----------
components: Windows
files: Capture.PNG
messages: 397850
nosy: paul.moore, steve.dower, therenoisfood, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: time.sleep(0.001) not working properly
versions: Python 3.9
Added file: https://bugs.python.org/file50161/Capture.PNG

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

From report at bugs.python.org  Tue Jul 20 00:09:05 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Tue, 20 Jul 2021 04:09:05 +0000
Subject: [New-bugs-announce] [issue44682] Pdb commands allows to add
 commands to invalid breakpoint
Message-ID: <1626754145.37.0.320226064648.issue44682@roundup.psfhosted.org>


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

breakpoint 5 does not exist:

(Pdb) commands 5
(com) p x
(com)
(com) end

----------
components: Library (Lib)
messages: 397852
nosy: andrei.avk
priority: normal
severity: normal
status: open
title: Pdb commands allows to add commands to invalid breakpoint
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jul 20 08:58:24 2021
From: report at bugs.python.org (Mykyta)
Date: Tue, 20 Jul 2021 12:58:24 +0000
Subject: [New-bugs-announce] [issue44683] String formatting
Message-ID: <1626785904.54.0.269807586162.issue44683@roundup.psfhosted.org>


New submission from Mykyta <poberezhniyn at icloud.com>:

The formatting does not work correctly.

I have a dict with string representations of integers as keys, such as {'1': 'a'} and trying to format it this way: '{0[1]}' and KeyError occurs. But I think it should not as '{0[a]}'.format(a) works properly with a = {'a': '1'} and '{0[1]}'.format(a) works properly with a = {1: 'a'}. Adding quotation marks does not help, KeyError occurs with '"1"'.

----------
components: Unicode
files: 1.png
messages: 397867
nosy: NickP, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: String formatting
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50166/1.png

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

From report at bugs.python.org  Tue Jul 20 10:38:46 2021
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 20 Jul 2021 14:38:46 +0000
Subject: [New-bugs-announce] [issue44684] Docs for mock.call
Message-ID: <1626791926.02.0.184089521055.issue44684@roundup.psfhosted.org>


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

The docs for `mock.call` could get improved:

https://docs.python.org/3/library/unittest.mock.html#call

Up to now it is not clear how to access individual members of the call.

Example: I want to check if the call used the kwarg "foo" with the value of "bar".

Usually you don't need this, since you check for the whole call (all args and all kwargs).

But sometimes you jus twant to check for a single arg/kwarg.

Then it would be nice to have more detailed docs for the class "call".

BTW: Why has this class a lower-case name? Looks a bit strange.

----------
assignee: docs at python
components: Documentation
messages: 397874
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: Docs for mock.call
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 20 12:02:15 2021
From: report at bugs.python.org (Heghine)
Date: Tue, 20 Jul 2021 16:02:15 +0000
Subject: [New-bugs-announce] [issue44685] Email package issue with Outlook
 msg files
Message-ID: <1626796935.18.0.522723051399.issue44685@roundup.psfhosted.org>


New submission from Heghine <heghine.ghazaryan at siemplify.co>:

The email package has an issue with extracting the attachments from the email if the email is sent with the Outlook application with .msg files.

When I'm sending an email from the Outlook app by attaching .msg files to the email, the recipient receives the email but instead of .msg files, the email contains .eml files. So Outlook auto transforms the attached .msg to .eml.
When I'm trying to read and extract attachments with the email package by using the Message class "get_payload" method, the extracted data for the mentioned attachment doesn't contain necessary information like "content-disposition" or "filename", so working with that attachment is impossible.

For all other .eml files everything works fine. The issue exists only in the case of transformed .eml files. However, that .eml looks like any other eml file in the received mail.

----------
components: email
files: msg file.msg
messages: 397885
nosy: barry, heghine, r.david.murray
priority: normal
severity: normal
status: open
title: Email package issue with Outlook msg files
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50167/msg file.msg

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

From report at bugs.python.org  Tue Jul 20 15:29:08 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 20 Jul 2021 19:29:08 +0000
Subject: [New-bugs-announce] [issue44686] use pkgutil.resolve_name in
 unittest.mock
Message-ID: <1626809348.44.0.635818901045.issue44686@roundup.psfhosted.org>


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

per https://bugs.python.org/issue12915 pkgutil.resolve_name was added for use in mock and other stdlib modules:

> pydoc has locate and resolve, packaging has util.resolve_name, unittest has something else, etc.

----------
messages: 397905
nosy: graingert
priority: normal
pull_requests: 25814
severity: normal
status: open
title: use pkgutil.resolve_name in unittest.mock
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 20 16:42:34 2021
From: report at bugs.python.org (liquidpele)
Date: Tue, 20 Jul 2021 20:42:34 +0000
Subject: [New-bugs-announce] [issue44687] io.BufferedReader:peek() closes
 underlying file, breaking peek/read expectations
Message-ID: <1626813754.71.0.447249212898.issue44687@roundup.psfhosted.org>


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

reecepeg at 3c22fb7d6b37 Pulpmill % python3 --version
Python 3.9.1


When buffering a small file, calling peek() can read in the entire underlying thing and close it, so then following with a read() throws an error about the file being closed already even though peek should not have that effect. 

Reproducible Steps:

>>> r = BufferedReader(requests.get("https://google.com", stream=True).raw)
>>> r.peek(2)[:2]
b'\x1f\x8b'
>>> r.peek()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: peek of closed file
>>> r.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: read of closed file


However, in the case of a larger stream it appears to work since the underlying stream isn't closed yet:

>>> r = BufferedReader(requests.get("https://amazon.com", stream=True).raw)
>>> r.peek(2)[:2]
b'\x1f\x8b'
>>> r.peek(2)[:2]
b'\x1f\x8b'


This seems inconsistent at best. Best I can tell, the issue is here and needs to take the current buffer offset into account. 
https://github.com/python/cpython/blob/main/Modules/_io/bufferedio.c#L845

----------
components: IO
messages: 397907
nosy: liquidpele
priority: normal
severity: normal
status: open
title: io.BufferedReader:peek() closes underlying file, breaking peek/read expectations
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 20 17:13:59 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 20 Jul 2021 21:13:59 +0000
Subject: [New-bugs-announce] [issue44688] [sqlite3] Remove ASCII limitation
 from sqlite3.Connection.create_collation()
Message-ID: <1626815639.0.0.124949004074.issue44688@roundup.psfhosted.org>


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

The sqlite3.Connection.create_collation() function limits collation names to ASCII characters only. As sqlite3_create_collation_v2() (and sqlite3_create_collation()) support UTF8, there is no need for this limitation anymore.

See https://github.com/python/cpython/pull/27156#issuecomment-883694653

----------
assignee: erlendaasland
components: Extension Modules
messages: 397912
nosy: erlendaasland, petr.viktorin
priority: normal
severity: normal
status: open
title: [sqlite3] Remove ASCII limitation from sqlite3.Connection.create_collation()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 20 17:56:46 2021
From: report at bugs.python.org (Tobias Bergkvist)
Date: Tue, 20 Jul 2021 21:56:46 +0000
Subject: [New-bugs-announce] [issue44689] MacOS: Python binaries not
 portable between Catalina and Big Sur
Message-ID: <1626818206.09.0.214441719603.issue44689@roundup.psfhosted.org>


New submission from Tobias Bergkvist <tobias at bergkv.ist>:

Python-binaries compiled on either Big Sur or Catalina - and moved to the other MacOS-version will not work as expected when code depends on ctypes.util.find_library.

Example symptom of this issue: https://github.com/jupyterlab/jupyterlab/issues/9863
I have personally faced this when using Python from nixpkgs - since nixpkgs Python has been built on Catalina - and I'm using Big Sur.


Scenario 1: Compile on Catalina, copy binaries to BigSur, and call ctypes.util.find_library('c')
Python 3.11.0a0 (heads/main:635bfe8162, Jul 19 2021, 08:09:05) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes.util import find_library; print(find_library('c'))
None

Scenario 2: Compile on Big Sur, copy binaries to Catalina, and call ctypes.util.find_library('c'):
Python 3.11.0a0 (heads/main:635bfe8162, Jul 19 2021, 08:28:48) [Clang 12.0.5 (clang-1205.0.22.11)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes.util import find_library; print(find_library('c'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/ctypes/__init__.py", line 8, in <module>
    from _ctypes import Union, Structure, Array
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: dlopen(/usr/local/lib/python3.11/lib-dynload/_ctypes.cpython-311-darwin.so, 2): Symbol not found: __dyld_shared_cache_contains_path
  Referenced from: /usr/local/lib/python3.11/lib-dynload/_ctypes.cpython-311-darwin.so (which was built for Mac OS X 11.4)
  Expected in: /usr/lib/libSystem.B.dylib
 in /usr/local/lib/python3.11/lib-dynload/_ctypes.cpython-311-darwin.so

----------
components: ctypes
messages: 397916
nosy: bergkvist
priority: normal
pull_requests: 25816
severity: normal
status: open
title: MacOS: Python binaries not portable between Catalina and Big Sur
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jul 20 17:57:36 2021
From: report at bugs.python.org (Idan Moral)
Date: Tue, 20 Jul 2021 21:57:36 +0000
Subject: [New-bugs-announce] [issue44690] Adopt binacii.a2b_base64's strict
 mode in base64.b64decode
Message-ID: <1626818256.45.0.373140812425.issue44690@roundup.psfhosted.org>


New submission from Idan Moral <idan22moral at gmail.com>:

This is a follow-up PR to GH-24402.

Currently, *base64.b64decode* uses a generic regex to validate *s* (when *validate* is true),
which sometimes results in unexpected behavior and exception messages.

Example:

(1)    base64.b64decode('ab==',  validate=True) # b'i'
(2)    base64.b64decode('ab3==', validate=True) # b'i\xbd'
(3)    base64.b64decode('ab=3=', validate=True) # raises binascii.Error: Non-base64 digit found
(4)    base64.b64decode('ab==3', validate=True) # raises binascii.Error: Non-base64 digit found
(5)    base64.b64decode('ab===', validate=True) # raises binascii.Error: Non-base64 digit found
(6)    base64.b64decode('=ab==', validate=True) # raises binascii.Error: Non-base64 digit found

The only strict-base64 valid example here is (1).
(2), (4) and (5) should raise 'Excess data after padding',
(3) should raise 'Discontinuous padding not allowed',
and (6) should raise 'Leading padding not allowed'.

To get this behavior, we can use the new (at the time of creating this PR) *binascii.a2b_base64* functionality of strict mode.

I have one (not so big) concern - efficiency.
I'm not that experienced with how fast regex-es are (in Python or in general) compared to the implementation of *binascii.a2b_base64* in C.
So, I've no idea what would be the impact of migrating from regex pre-validation to input parsing.
Let me know if you find it inefficient.

-----

Referenced issue (GH-24402): https://bugs.python.org/issue43086

----------
components: Library (Lib)
messages: 397917
nosy: idan22moral
priority: normal
severity: normal
status: open
title: Adopt binacii.a2b_base64's strict mode in base64.b64decode
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 20 19:01:09 2021
From: report at bugs.python.org (pierpaolo paolucci)
Date: Tue, 20 Jul 2021 23:01:09 +0000
Subject: [New-bugs-announce] [issue44691] bug in interactions between
 argparse and random
Message-ID: <1626822069.01.0.152185691675.issue44691@roundup.psfhosted.org>


New submission from pierpaolo paolucci <peeble111 at gmail.com>:

Python 3.9.6 (default, Jun 28 2021, 11:30:47) 
[GCC 10.3.0] on linux

I tried to run the first time a prg and successively reproduce eventals error

see the attachment

----------
components: Library (Lib)
files: testRandom.py
messages: 397918
nosy: peeble111
priority: normal
severity: normal
status: open
title: bug in interactions between argparse and random
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50168/testRandom.py

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

From report at bugs.python.org  Wed Jul 21 01:18:16 2021
From: report at bugs.python.org (anthony shaw)
Date: Wed, 21 Jul 2021 05:18:16 +0000
Subject: [New-bugs-announce] [issue44692] Const unfolding in parser with
 negative numbers doesn't match float/int behaviour
Message-ID: <1626844696.89.0.509830033076.issue44692@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

Powers with negative bases do not observe the same rules that float_pow/long_pow do when it comes to returning negative results/

Example:

> -2 ** 2
-4

>>> x = -2
>>> y = 2
>>> x ** y
4

>>> -2. ** 2.
-4.0
>>> x = -2.
>>> y = 2.
>>> x ** y
4.0

Tested on 3.8, 3.9 and 3.10, they all have the same bug.

----------
components: Parser
messages: 397922
nosy: anthonypjshaw, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Const unfolding in parser with negative numbers doesn't match float/int behaviour
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 21 04:45:17 2021
From: report at bugs.python.org (Steven Hsu)
Date: Wed, 21 Jul 2021 08:45:17 +0000
Subject: [New-bugs-announce] [issue44693] Unclear definition of the
 "__future__" module in Docs
Message-ID: <1626857117.48.0.847566254974.issue44693@roundup.psfhosted.org>


New submission from Steven Hsu <hsuhaochun at gmail.com>:

In Doc/glossary.rst, the first sentence of the entry "__future__" is that "A pseudo-module which programmers can use to enable new language features which are not compatible with the current interpreter."

However, in Doc/library/__future__.rst, the first sentence is that ":mod:`__future__` is a real module, and serves three purposes:"

Is there any contradiction of these two descriptions, that "pseuso-module" and "real module" refer to the same module?

And if so, should we fix one of them?

Thanks for review!

----------
assignee: docs at python
components: Documentation
messages: 397931
nosy: StevenHsuYL, docs at python
priority: normal
severity: normal
status: open
title: Unclear definition of the "__future__" module in Docs
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Jul 21 07:06:27 2021
From: report at bugs.python.org (Vitas Ivanoff)
Date: Wed, 21 Jul 2021 11:06:27 +0000
Subject: [New-bugs-announce] [issue44694] Message from BytesParser cannot be
 flattened immediately
Message-ID: <1626865587.67.0.966185604714.issue44694@roundup.psfhosted.org>


New submission from Vitas Ivanoff <vitas1 at gmail.com>:

Hello. Here is my code:
#Parse message from file and immediately flatten it
cur_policy = email.policy.SMTPUTF8
with open("/tmp/0.tmp", "rb") as orig_message_file:
    message_bytes = orig_message_file.read()
message_parser = BytesParser(policy=cur_policy)
msg = message_parser.parsebytes(message_bytes)
with open("/tmp/1.tmp", "wb") as new_message_file:
    message_gen = BytesGenerator(new_message_file, policy=cur_policy)
message_gen.flatten(msg)

On some messages script raises the following error:

Traceback (most recent call last):
  File "/misc/parsemail/./1.py", line 34, in <module>
    message_gen.flatten(msg)
  File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
    self._write(msg)
  File "/usr/lib/python3.9/email/generator.py", line 199, in _write
    self._write_headers(msg)
  File "/usr/lib/python3.9/email/generator.py", line 422, in _write_headers
    self._fp.write(self.policy.fold_binary(h, v))
  File "/usr/lib/python3.9/email/policy.py", line 200, in fold_binary
    folded = self._fold(name, value, refold_binary=self.cte_type=='7bit')
  File "/usr/lib/python3.9/email/policy.py", line 214, in _fold
    return self.header_factory(name, ''.join(lines)).fold(policy=self)
  File "/usr/lib/python3.9/email/headerregistry.py", line 257, in fold
    return header.fold(policy=policy)
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 156, in fold
    return _refold_parse_tree(self, policy=policy)
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 2825, in _refold_parse_tree
    last_ew = _fold_as_ew(tstr, lines, maxlen, last_ew,
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 2913, in _fold_as_ew
    encoded_word = _ew.encode(to_encode_word, charset=encode_as)
  File "/usr/lib/python3.9/email/_encoded_words.py", line 222, in encode
    bstring = string.encode('ascii', 'surrogateescape')
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)

Policies 'default' and 'SMTP' are also affected. 

How to fix:

#For broken messages
message_gen = BytesGenerator(new_message_file, policy=cur_policy, maxheaderlen=0)

Well, but parsing and flattening the same *unmodified* message should be completed without using any additional parameters, isn't it?
Thanks.

----------
components: email
messages: 397937
nosy: barry, r.david.murray, vitas1
priority: normal
severity: normal
status: open
title: Message from BytesParser cannot be flattened immediately
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 21 07:29:22 2021
From: report at bugs.python.org (Itay azolay)
Date: Wed, 21 Jul 2021 11:29:22 +0000
Subject: [New-bugs-announce] [issue44695] asdict use deep copy to dataclass
 instances
Message-ID: <1626866962.24.0.087690350539.issue44695@roundup.psfhosted.org>


New submission from Itay azolay <itayazolay at gmail.com>:

Hi, 
I noticed that 'asdict' use 'deepcopy' on all fields of the dataclass recursively. 
I believe this behavior can become optional with an argument, and shouldn't be decided for the user as the deepcopy takes significant amount of cpu and can have unexpected consequences on memory.

I don't mind taking this PR if you agree. 
Thanks

----------
components: Library (Lib)
messages: 397938
nosy: Itayazolay
priority: normal
severity: normal
status: open
title: asdict use deep copy to dataclass instances
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 21 08:21:46 2021
From: report at bugs.python.org (chen-y0y0)
Date: Wed, 21 Jul 2021 12:21:46 +0000
Subject: [New-bugs-announce] [issue44696] Python 2.0.1 Installation:
Message-ID: <1626870106.9.0.48016161015.issue44696@roundup.psfhosted.org>


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

# I tried to install Python 2.0.1 onto my virtual machine(Windows 3.1) for low-version developing, but an error occurred while the installation:
#             Error
# Could not load the DLL library
# C:\TEMP\~GLF256B.TMP.

----------
components: IO, Installation, Library (Lib), Windows
messages: 397941
nosy: paul.moore, prasechen, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 2.0.1 Installation:
type: crash

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

From report at bugs.python.org  Wed Jul 21 09:46:19 2021
From: report at bugs.python.org (Artem)
Date: Wed, 21 Jul 2021 13:46:19 +0000
Subject: [New-bugs-announce] [issue44697] Memory leak when
 asyncio.open_connection raise
Message-ID: <1626875179.77.0.215331684735.issue44697@roundup.psfhosted.org>


New submission from Artem <doomedseer at GMail.com>:

I write some short example.

import resource
import asyncio


class B:
    def __init__(self, loop):
        self.loop = loop
        self.some_big_data = bytearray(1024 * 1024)  # 1Mb for memory bloating

    async def doStuff(self):
        if not await self.connect():
            return
        print('Stuff done')

    async def connect(self) -> bool:
        try:
            _, writer = await asyncio.open_connection('127.0.0.1', 12345, loop=self.loop)
            writer.close()
            return True
        except OSError as e:
            pass
        return False


class A:
    def __init__(self, loop):
        self.loop = loop

    async def doBStuff(self):
        b = B(self.loop)
        await b.doStuff()

    async def work(self):
        print('Working...')
        for _ in range(1000):
            await self.loop.create_task(self.doBStuff())
        print('Done.')
        print(
            'Memory usage {}kb'.format(
                resource.getrusage(
                    resource.RUSAGE_SELF).ru_maxrss))


async def amain(loop):
    a = A(loop)
    await a.work()


if __name__ == "__main__":
    loop = asyncio.get_event_loop()
    loop.run_until_complete(amain(loop))


100 cycles
"Memory usage 41980kb"

1000 cycles
"Memory usage 55412kb"

10000 cycles
"Memory usage 82880kb"

And so on...

Does anyone know workaround?

----------
components: asyncio
messages: 397945
nosy: aeros, asvetlov, seer, yselivanov
priority: normal
severity: normal
status: open
title: Memory leak when asyncio.open_connection raise
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Wed Jul 21 11:06:49 2021
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 21 Jul 2021 15:06:49 +0000
Subject: [New-bugs-announce] [issue44698] Undefined behaviour in
 Objects/complexobject.c's complex_pow
Message-ID: <1626880009.97.0.704529118942.issue44698@roundup.psfhosted.org>


New submission from Thomas Wouters <thomas at python.org>:

Objects/complexobject.c's complex_pow uses undefined behaviour, by casting a float of unknown magnitude to a long:

    int_exponent = (long)exponent.real;

At Google we build with clang and -fsanitize=float-cast-overflow by default, which catches this particular kind of undefined behaviour. We didn't notice, however, because the only code we've come across that exercises this behaviour was a commented-out test in test_complex, which was uncommented in 3.8. Running the test, or just '1e19+1j ** 1e19', is enough to trigger the undefined behaviour. I'll prepare a PR to fix it.

----------
assignee: twouters
messages: 397947
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
status: open
title: Undefined behaviour in Objects/complexobject.c's complex_pow
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 21 11:21:57 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=A1nos_Brezniczky?=)
Date: Wed, 21 Jul 2021 15:21:57 +0000
Subject: [New-bugs-announce] [issue44699] Simple regex appears to take
 exponential time in length of input
Message-ID: <1626880917.83.0.0892531059117.issue44699@roundup.psfhosted.org>


New submission from J?nos Brezniczky <brezniczky at gmail.com>:

I don't know if it's normal, but it's impractical.
I seem to have come by an expression consuming o(c^n) CPU cycles with c around 2.

Regex:
\*([^*]+)*\*

Resulted in times (in seconds) of 

0.17   (* is there anybody out?)
0.34 1
0.69 12
1.36 123
2.73  1234
5.44  12345
11.1  123456  (* is there anybody123456 out?)


Please see the source for more details/repro.

----------
components: Regular Expressions
files: regex_test.py
messages: 397948
nosy: brezniczky, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Simple regex appears to take exponential time in length of input
type: performance
versions: Python 3.8
Added file: https://bugs.python.org/file50169/regex_test.py

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

From report at bugs.python.org  Wed Jul 21 14:09:03 2021
From: report at bugs.python.org (Jack DeVries)
Date: Wed, 21 Jul 2021 18:09:03 +0000
Subject: [New-bugs-announce] [issue44700] Python fails to build
 (aarch64-apple-darwin20.5.0)
Message-ID: <1626890943.41.0.549645989366.issue44700@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

I believe this is a problem with my machine because I've tried checking out to known good commits (which worked on my machine before) and have the same issue, but I've tried everything and don't really know what to do next. I'm hoping someone can help me, and who knows ??maybe it is a bug!

This is the command that fails::

   gcc  -Wl,-stack_size,1000000  -framework CoreFoundation \
      -o Programs/_testembed Programs/_testembed.o libpython3.11d.a -ldl   \
      -framework CoreFoundation

The linker is ignoring `libpython3.11d.a`, providing the following warning::

   ignoring file libpython3.11d.a, building for macOS-arm64 but attempting to link with file 
   built for macOS-arm64

Of course, what follows is a ton of undefined symbol errors; no surprises there. I don't understand how to fix the error, why it is happening, or how this issue could have possibly cropped up overnight. These are the things I've tried to fix it:

1. Run autoconf to regenerate the configure script.
2. Delete everything. Reconfigure and rebuild from a clean slate.
3. Comment out `.zshenv`, `.zshrc`, and `.zprofile`
4. Try configuring and compiling on bash and sh instead of zsh

----------
components: Build
messages: 397957
nosy: jack__d
priority: normal
severity: normal
status: open
title: Python fails to build (aarch64-apple-darwin20.5.0)

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

From report at bugs.python.org  Wed Jul 21 15:07:38 2021
From: report at bugs.python.org (Leonardo Freua)
Date: Wed, 21 Jul 2021 19:07:38 +0000
Subject: [New-bugs-announce] [issue44701] Create a @deprecated decorator
 (annotation)
Message-ID: <1626894458.82.0.833124063655.issue44701@roundup.psfhosted.org>


New submission from Leonardo Freua <leonardo.batista.freua at gmail.com>:

Would it be interesting to create a @deprecated decorator to avoid adding warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in methods body?

Using the decorator approach to indicate depreciation would make the methods cleaner (leaving only their responsibilities in the body) and would be easier to identify, as the cue would be close to the method signature and not mixed with the logic inside the body.

If everyone agrees, I could submit a PR (as a draft) for us to evaluate this functionality.

----------
components: Library (Lib)
messages: 397958
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Create a @deprecated decorator (annotation)
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul 21 16:30:56 2021
From: report at bugs.python.org (Svyatoslav)
Date: Wed, 21 Jul 2021 20:30:56 +0000
Subject: [New-bugs-announce] [issue44702] Fix weakref doc
Message-ID: <1626899456.99.0.316409007045.issue44702@roundup.psfhosted.org>


New submission from Svyatoslav <prometheus3375 at gmail.com>:

>From https://docs.python.org/3/library/weakref.html:
""
Not all objects can be weakly referenced; those objects which can include class instances, functions written in Python (but not in C), instance methods, sets, frozensets, some file objects, generators, type objects, sockets, arrays, deques, regular expression pattern objects, and code objects.
""

My first perception was that this is the list of objects without weakref support. Actually, the sentence lists objects which do support weakref. While writing this report I understood: "can" does not relate to "include" at all. The correct way of reading is "those objects | which can | include ...". Previously I had read it as "those objects | which can include ...". Even Google translates in such manner, commas do not help.

To remove ambguity, I suggest such fix:
""
Not all objects can be weakly referenced. Objects which support weak references include class instances, functions written in Python (but not in C), instance methods, sets, frozensets, some file objects, generators, type objects, sockets, arrays, deques, regular expression pattern objects, and code objects.
""
or
""
Not all objects can be weakly referenced. ?lass instances, functions written in Python (but not in C), instance methods, sets, frozensets, some file objects, generators, type objects, sockets, arrays, deques, regular expression pattern objects, and code objects support weak references.
""

----------
assignee: docs at python
components: Documentation
messages: 397960
nosy: Prometheus3375, docs at python
priority: normal
severity: normal
status: open
title: Fix weakref doc
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 21 17:20:08 2021
From: report at bugs.python.org (Svyatoslav)
Date: Wed, 21 Jul 2021 21:20:08 +0000
Subject: [New-bugs-announce] [issue44703] deepcopy(frozenset()) returns a
 new object
Message-ID: <1626902408.34.0.16297036439.issue44703@roundup.psfhosted.org>


New submission from Svyatoslav <prometheus3375 at gmail.com>:

from copy import copy, deepcopy
t = 1, 2
t1 = t, 3
t2 = t1, 4
t3 = t2, 5
assert copy(t3) is t3
assert deepcopy(t3) is t3

s = frozenset({1, 2})
assert s.copy() is s  # method .copy() always returns self, what its purpose?
assert copy(s) is s
assert deepcopy(s) is s  # raises AssertionError


Even a deepcopy of a tuple with many nested tuples is the the tuple itself, while a deepcopy of a frozenset which by definition cannot contain mutable objects is a new frozenset.
I think it is an error. A new frozenset is created because deepcopy() fallbacks to pickling.

----------
components: Library (Lib)
messages: 397961
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: deepcopy(frozenset()) returns a new object
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 21 17:32:14 2021
From: report at bugs.python.org (Svyatoslav)
Date: Wed, 21 Jul 2021 21:32:14 +0000
Subject: [New-bugs-announce] [issue44704] frozenset.__hash__ vs. Set._hash
Message-ID: <1626903134.43.0.638660457215.issue44704@roundup.psfhosted.org>


New submission from Svyatoslav <prometheus3375 at gmail.com>:

In docstring of Set._hash in _collections_abc.py is written:
"We match the algorithm used by the built-in frozenset type."

But
>>> s = frozenset({i for i in range(10)})
>>> hash(s)
3895031357313128696
>>> Set._hash(s)
3914343279946282847

Looks like Set._hash is different.

----------
components: Library (Lib)
messages: 397963
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: frozenset.__hash__ vs. Set._hash
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 21 20:15:18 2021
From: report at bugs.python.org (Luke Deller)
Date: Thu, 22 Jul 2021 00:15:18 +0000
Subject: [New-bugs-announce] [issue44705] Support Windows file open modes
 for `open` built-in function
Message-ID: <1626912918.78.0.0995473135794.issue44705@roundup.psfhosted.org>


New submission from Luke Deller <lukedeller1 at gmail.com>:

Microsoft Windows supports some extra file open modes including:
 "S" 	Specifies that caching is optimized for, but not restricted to, sequential access from disk.
 "T" 	Specifies a file as temporary. If possible, it is not flushed to disk.
 "D" 	Specifies a file as temporary. It is deleted when the last file pointer is closed

Python 2 used to allow "T" and "D" flags in the built-in `open` function (though this was not documented):
https://github.com/python/cpython/blob/2.7/Objects/fileobject.c#L214

It would be great if these flags were allowed in Python 3.

I see that Python3 implementation uses `open`/`_wopen` rather than `fopen` now.  The mapping to numeric flags for `_wopen` is shown in the documentation here:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen (search for "Equivalent oflag value")

----------
components: IO
messages: 397971
nosy: lukedeller1
priority: normal
severity: normal
status: open
title: Support Windows file open modes for `open` built-in function
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jul 22 02:06:33 2021
From: report at bugs.python.org (Tzach Yarimi)
Date: Thu, 22 Jul 2021 06:06:33 +0000
Subject: [New-bugs-announce] [issue44706] UUID constructor should accept
 another UUID instance
Message-ID: <1626933993.3.0.670473519068.issue44706@roundup.psfhosted.org>


Change by Tzach Yarimi <tzachyrm at gmail.com>:


----------
components: Library (Lib)
nosy: tzach
priority: normal
severity: normal
status: open
title: UUID constructor should accept another UUID instance
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul 22 03:16:09 2021
From: report at bugs.python.org (=?utf-8?b?U3Jpbml2YXMgIFJlZGR5IFRoYXRpcGFydGh5KOCwtuCxjeCwsOCxgOCwqA==?= =?utf-8?b?4LC/4LC14LC+4LC44LGNIOCwsOCxhuCwoeCxjeCwoeCwvyDgsKTgsL7gsJ8=?= =?utf-8?b?4LC/4LCq4LCw4LGN4LCk4LC/KQ==?=)
Date: Thu, 22 Jul 2021 07:16:09 +0000
Subject: [New-bugs-announce] [issue44707] runtime error: applying zero
 offset to null pointer in Objects/listobject.c
Message-ID: <1626938169.25.0.820707570973.issue44707@roundup.psfhosted.org>


New submission from Srinivas  Reddy Thatiparthy(?????????? ?????? ?????????) <thatiparthysreenivas at gmail.com>:

After seeing this issue https://bugs.python.org/issue44698, I wanted to run clang on the main branch (c878f5d81772dc6f718d6608c78baa4be9a4f176) with an undefined option enabled.

Is the following a bug or false positive?

Objects/listobject.c:527:24: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior Objects/listobject.c:527:24 in


Steps to reproduce.
1. export CC="/usr/bin/clang -fsanitize=undefined"
2. ./configure --with-pydebug --with-openssl=$(brew --prefix openssl)
3. make -j

Meta :
? clang --version
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

? uname -a
Darwin Srinivass-MBP.Dlink 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64

----------
messages: 397978
nosy: thatiparthy
priority: normal
severity: normal
status: open
title: runtime error: applying zero offset to null pointer in Objects/listobject.c

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

From report at bugs.python.org  Thu Jul 22 10:32:29 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 22 Jul 2021 14:32:29 +0000
Subject: [New-bugs-announce] [issue44708] Regression tests with -w should
 only re-run affected test methods, not the entire file
Message-ID: <1626964349.84.0.902926584101.issue44708@roundup.psfhosted.org>


New submission from ?ukasz Langa <lukasz at langa.pl>:

When the CPython test suite re-runs a flaky failed test, it doesn?t actually re-run just that failed test but the entire test file. The most common case for flaky tests is when networking, threading, or multiprocessing is involved. Frustratingly those are some of the largest test files we have. Re-running them takes a lot of time.

Instead of re-running the entire file, regrtest should only re-run what actually failed.

NOTE: I added 3.10 and 3.9 to this issue even though it's not a pure bugfix. The reason is that this can visibly speed up CI for open pull requests.

(Of course, it would be best to avoid flaky tests altogether and we?re working on that, but re-running what failed is a pragmatic stopgap that is necessary in times of distributed CI that we don?t fully control.)

----------
assignee: lukasz.langa
components: Tests
messages: 397985
nosy: lukasz.langa, pablogsal
priority: normal
severity: normal
stage: patch review
status: open
title: Regression tests with -w should only re-run affected test methods, not the entire file
type: resource usage
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Jul 22 12:00:26 2021
From: report at bugs.python.org (San)
Date: Thu, 22 Jul 2021 16:00:26 +0000
Subject: [New-bugs-announce] [issue44709] [3.7] Popen Control Characters in
 stdout affect shell session
Message-ID: <1626969626.94.0.722055319986.issue44709@roundup.psfhosted.org>


New submission from San <elias.haag at web.de>:

I was trying to wrap an old game server executable with a built-in console using Popen.

class ServerWrapper(Thread):
    def __init__(self, pathToExecutable: str, statusMonitor: Popen = None, active: bool = False):
        super().__init__()
        self.pathToExecutable = pathToExecutable
        self.statusMonitor = statusMonitor
        self.active = active

    def run(self):
        self.statusMonitor = Popen(['./bf1942_lnxded', "+statusMonitor", '1'], encoding='latin_1', stdout=PIPE,
                                   stdin=PIPE, cwd=self.pathToExecutable)
        while self.active:
            currentLine = self.statusMonitor.stdout.readline()
            if currentLine:
                print(currentLine)
                input('')

    def start(self):
        self.active = True
        super().start()

    def stop(self):
        self.active = False



I expected to be able to read the output line-by-line using enter, in a 'normal fashion'.
After importing this from a terminal and setting it up somewhat like so:

wrapper = ServerWrapper('bf1942')
wrapper.start()

However, once the server process started and thereby started writing to stdout, weird stuff started to happen to my shell with the python interpreter.

Apparently, there are control characters and ansi-escape codes sent from the process, that somehow manage to manipulate my shell if I specify an encoding. Consequentially the lines output with 'print(currentLine)' are reduced by these chars.

Is this the desired behaviour of the decoder? If so then I think this should potentially be further clarified in the documentation of Popen. I would have expected the chars to be escaped because the worst thing is, this happens even if you don't actually read from stdout at all. Seemingly the decoder executes incoming control sequences immediately (probably for the buffer?), regardless of if you actually bother to read the stdout or not.

The paragraph in https://docs.python.org/3.7/library/subprocess.html#security-considerations sounds like this shouldn't be happening if 'shell' is not set to 'True' at least.

----------
files: shell.png
messages: 397986
nosy: San
priority: normal
severity: normal
status: open
title: [3.7] Popen Control Characters in stdout affect shell session
versions: Python 3.7
Added file: https://bugs.python.org/file50170/shell.png

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

From report at bugs.python.org  Thu Jul 22 12:35:42 2021
From: report at bugs.python.org (Cheuk Ting Ho)
Date: Thu, 22 Jul 2021 16:35:42 +0000
Subject: [New-bugs-announce] [issue44710] Unexpected behavior in empty class
 with pass (Python 3.7.3)
Message-ID: <1626971742.78.0.379614893398.issue44710@roundup.psfhosted.org>


New submission from Cheuk Ting Ho <cheukting.ho at gmail.com>:

Demo example:

===================
class MyType(type):
    def __init__(cls, name, bases, nmspc):

        if "__annotations__" in nmspc:
            annotations = nmspc["__annotations__"]
        else:
            nmspc["__annotations__"] = {}
            annotations = nmspc["__annotations__"]

        for parent in bases:
            base_annotations = (
                parent.__annotations__ if hasattr(parent, "__annotations__") else {}
            )
            annotations.update(base_annotations)

        super().__init__(name, bases, nmspc)

class Coordinate(metaclass=MyType):
    x: float
    y: float

class Address(metaclass=MyType):
    street: str
    country: str


class Location(Address, Coordinate):
    pass


class Location2(Address, Coordinate):
    name: str


print(Location.__annotations__)
print(Location2.__annotations__)
================
Output:

{'street': <class 'str'>, 'country': <class 'str'>}
{'name': <class 'str'>, 'street': <class 'str'>, 'country': <class 'str'>, 'x': <class 'float'>, 'y': <class 'float'>}

Was expecting the two print to be only different by 'name': <class 'str'> but the `Location fails to inherit the attribute from `Coordinate`. Not the case for `Location2`


*it's my first time submitting an issue, please kindly tell me what to do if I am not doing the right thing.

----------
components: C API
messages: 397988
nosy: Cheukting
priority: normal
severity: normal
status: open
title: Unexpected behavior in empty class with pass (Python 3.7.3)
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Jul 22 15:50:28 2021
From: report at bugs.python.org (Anton G.)
Date: Thu, 22 Jul 2021 19:50:28 +0000
Subject: [New-bugs-announce] [issue44711] Optimize type check in pipes.py
Message-ID: <1626983428.37.0.292600316.issue44711@roundup.psfhosted.org>


New submission from Anton G. <anton.gruebel at googlemail.com>:

When I did some work on typeshed I found some weird syntax in pipes.py.

if type(cmd) is not type(''):

which can easily be changed to

if not isinstance(cmd, str):

There are two occurrences and I will directly create the PR :)

----------
components: Library (Lib)
messages: 397995
nosy: anton.gruebel
priority: normal
severity: normal
status: open
title: Optimize type check in pipes.py
type: performance

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

From report at bugs.python.org  Thu Jul 22 16:41:11 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Jul 2021 20:41:11 +0000
Subject: [New-bugs-announce] [issue44712] Replace `type(literal)` with
 corresponding builtin types
Message-ID: <1626986471.98.0.436610073153.issue44712@roundup.psfhosted.org>


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

There are several occurrences of type(literal) in the code of the stdlib where literal is a literal of built-in type: '', 1, [], {}, etc. I suppose it is a remnants of very old code written when str, int, list, dict, etc were functions and not classes.

The proposed PR replaces `type(literal)` with corresponding builtin types. It makes the code cleaner.

I consider also idea of replacing identity or equality checks ("is" or "==") with isinstance(). I suppose that that code was written when built-in  types were not subclassable. But now there is a reason to use isinstance().

See also issue44711.

----------
components: Library (Lib)
messages: 398002
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Replace `type(literal)` with corresponding builtin types
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul 22 18:07:21 2021
From: report at bugs.python.org (Jack DeVries)
Date: Thu, 22 Jul 2021 22:07:21 +0000
Subject: [New-bugs-announce] [issue44713] subprocess.rst typo
 ``"shell=True"`` => ``shell=True``
Message-ID: <1626991641.24.0.753017266969.issue44713@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

Good feedback from @merwork just missed the merge, but he is right: it should be ``shell=True``, not ``"shell=True"``.

https://github.com/python/cpython/pull/26755#discussion_r675128438

I'll be attaching a PR in just a moment.

----------
messages: 398010
nosy: jack__d
priority: normal
severity: normal
status: open
title: subprocess.rst typo ``"shell=True"`` => ``shell=True``

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

From report at bugs.python.org  Thu Jul 22 20:51:19 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 23 Jul 2021 00:51:19 +0000
Subject: [New-bugs-announce] [issue44717] Improve AttributeError on circular
 imports of submodules
Message-ID: <1627001479.9.0.177247321024.issue44717@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

Consider the following


$ tree a
a
??? b
?   ??? c.py
?   ??? __init__.py
??? __init__.py

1 directory, 3 files
$ cat a/b/__init__.py
import a.b.c
$ cat a/b/c.py
import a.b

a.b
$ python
Python 3.9.6 (default, Jun 30 2021, 10:22:16)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import a.b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/anubis/test/a/b/__init__.py", line 1, in <module>
    import a.b.c
  File "/home/anubis/test/a/b/c.py", line 3, in <module>
    a.b
AttributeError: module 'a' has no attribute 'b'


This happens because even though the module `a` is initialized, the `b` attribute is not set due to the circular import. When a module is partially initialized, we get a more helpful error description hinting that we cannot access the attribute because the module is partially initialized, we could have something similar here.

----------
components: Interpreter Core
messages: 398021
nosy: FFY00, pablogsal
priority: normal
severity: normal
status: open
title: Improve AttributeError on circular imports of submodules
type: enhancement

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

From report at bugs.python.org  Fri Jul 23 00:25:27 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 23 Jul 2021 04:25:27 +0000
Subject: [New-bugs-announce] [issue44718] Incorrect arguments in function
 select() cause segfault
Message-ID: <1627014327.38.0.022368113605.issue44718@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

The following program can trigger segfault on all releases of Python. I think it may be caused  by incorrect arguments.

Version of Python: 3.6 - master(3.11.0a0)
system: ubuntu 16.04

test.py
================================
import select

def test_select_mutated():
    a = []

    class F:
        def fileno(a):
            del test_select_mutated()[-1]
            return sys.__stdout__.fileno()
    a[:] = [F()] * 10
    select.select([], a, []), ([], a[:5], [])

test_select_mutated()
================================

output:
---------------------------------------------------------------------
xxm at xxm:~$ '/home/xxm/Desktop/compiler/cpython-main/python'  test.py 
Segmentation fault (core dumped)
---------------------------------------------------------------------

----------
components: Interpreter Core
messages: 398027
nosy: xxm
priority: normal
severity: normal
status: open
title: Incorrect arguments in function select()  cause segfault
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jul 23 00:27:09 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 23 Jul 2021 04:27:09 +0000
Subject: [New-bugs-announce] [issue44719] Incorrect callable object crashes
 Python 3.11.0a0
Message-ID: <1627014429.86.0.790861111444.issue44719@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

This program can trigger "Aborted (core dumped)" on Python 3.9.0, Python 3.8.0, Python3.10.0a2.  It trigger " segmentation fault" on the master (Python 3.11.0a0).

==================================
import weakref

class Object:
    def __init__(self, arg):
        self.arg = arg

def test_set_callback_attribute():
    x = Object(1)
    callback = lambda ref: None
    callback = weakref.ref(callback, x)
    with test_set_callback_attribute():
        pass

test_set_callback_attribute()
==================================

Crashes on the master (Python 3.11.0a0)
------------------------------------------------------------
.....
Traceback (most recent call last):
  File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 26, in test_set_callback_attribute
    callback = weakref.ref(callback, x)
    ^^^^^^^^
TypeError: 'Object' object is not callable
Exception ignored in: <__main__.Object object at 0x7f3e2d56ca90>
Traceback (most recent call last):
  File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 26, in test_set_callback_attribute
Segmentation fault (core dumped)
--------------------------------------------------------------


Crashes on the older version of Python
-----------------------------------------------------------
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute
...
Aborted (core dumped)
---------------------------------------------------------------

System: Ubuntu 16.04

----------
components: Interpreter Core
messages: 398028
nosy: xxm
priority: normal
severity: normal
status: open
title: Incorrect callable object crashes Python 3.11.0a0
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul 23 01:05:41 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 23 Jul 2021 05:05:41 +0000
Subject: [New-bugs-announce] [issue44720] Finding string in iteratively
 deleted object cause segfault
Message-ID: <1627016741.96.0.306120219144.issue44720@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

This piece of code is originally from https://github.com/python/cpython/tree/main/Lib/test/test_weakref.py. In function test_proxy_iter(), we change the original data dependency and then this generated test case (see the following "test.py") crashes Python. 

Crashing Python version: 3.6-master(3.11.0a0)

test.py
=========================
import weakref


def test_proxy_iter():
    obj = None

    class MyObj:

        def __iter__(a):
            nonlocal obj
            del obj
-           return NotImplemented
+           return p
    obj = MyObj()
-   p = weakref.proxy(obj)
+   p = weakref.proxy(TypeError)

-   'blech' in p
+   'blech' in obj

test_proxy_iter()
===========================


system: ubuntu 16.04
crash: segmentation fault

----------
components: Interpreter Core
files: test.py
messages: 398029
nosy: xxm
priority: normal
severity: normal
status: open
title: Finding string in iteratively deleted object cause segfault
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50171/test.py

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

From report at bugs.python.org  Fri Jul 23 01:36:52 2021
From: report at bugs.python.org (Seyed Amirhossein Misaghi)
Date: Fri, 23 Jul 2021 05:36:52 +0000
Subject: [New-bugs-announce] [issue44721] Problem in tkinter button widget
Message-ID: <1627018612.93.0.785894598889.issue44721@roundup.psfhosted.org>


New submission from Seyed Amirhossein Misaghi <a.h.misaghi at gmail.com>:

Hello
The piece of code has false behavior. When click the button, the relief changes to tk.SUNKEN. I think this is a wrong behavior.
Thanks

----------
components: Tkinter
files: test.tar.gz
messages: 398031
nosy: a.h.misaghi
priority: normal
severity: normal
status: open
title: Problem in tkinter button widget
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50172/test.tar.gz

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

From report at bugs.python.org  Fri Jul 23 04:35:04 2021
From: report at bugs.python.org (creative-resort)
Date: Fri, 23 Jul 2021 08:35:04 +0000
Subject: [New-bugs-announce] [issue44722] RFC: string Multiline Formatter
Message-ID: <1627029304.73.0.520646474457.issue44722@roundup.psfhosted.org>


New submission from creative-resort <info at creative-resort.com>:

I'm opening this issue to propose the following enhancement
and a PR on GitHub.

Concerning: https://github.com/python/cpython/blob/main/Lib/string.py

The idea:
Format strings, that are comprised of field values with newlines (Multiline)
as Multiline strings in a quasi tabbed format.

--> In particular useful for logging of information, that occupies multiple lines.

For example: '{levelname}:{name}:{message}:{api}', 
             where the message and the api field is a string with multiple lines (contains newlines)

The result:   2021-07-23 09:50:28,981 module_name WARNING     Quota exceeded         Google-Cloud-API
                                                              Backing off for 5s     version: v1
                                                              after trying 2x

----------
components: Library (Lib)
messages: 398034
nosy: creative-resort
priority: normal
severity: normal
status: open
title: RFC: string Multiline Formatter
type: enhancement

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

From report at bugs.python.org  Fri Jul 23 06:18:59 2021
From: report at bugs.python.org (Bodo Graumann)
Date: Fri, 23 Jul 2021 10:18:59 +0000
Subject: [New-bugs-announce] [issue44723] Codec name normalization breaks
 custom codecs
Message-ID: <1627035539.3.0.918716906127.issue44723@roundup.psfhosted.org>


New submission from Bodo Graumann <mail at bodograumann.de>:

This is a follow up on https://bugs.python.org/issue37751 concerning normalization of codec names.

First of all, the changes made therein are not documented correctly.
In the implementation
| Normalization works as follows: all non-alphanumeric
| characters except the dot used for Python package names are
| collapsed and replaced with a single underscore, e.g. '  -;#'
| becomes '_'. Leading and trailing underscores are removed.?
Cf. [encodings/__init__.py](https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/encodings/__init__.py#L47-L50)

The documentation however only states that:
| Search functions are expected to take one argument, being the encoding name in all lower case letters with hyphens and spaces converted to underscores
Cf. https://docs.python.org/3/library/codecs.html#codecs.register

Secondly, this change breaks lots of iconv codecs with the python-iconv binding. E.g. `ASCII//TRANSLIT` is now normalized to `ascii_translit`, which iconv does not understand. Codec names which use hyphens also break and iinm not all of them have aliases in iconv without hyphens.
Cf. [python-iconv #4](https://github.com/bodograumann/python-iconv/issues/4)

How about first looking up the given name and only then, if the given name could not be found, looking for the codec by its normalized name?

----------
components: Unicode
messages: 398042
nosy: bodograumann, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Codec name normalization breaks custom codecs
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul 23 09:29:53 2021
From: report at bugs.python.org (Viktor Ivanov)
Date: Fri, 23 Jul 2021 13:29:53 +0000
Subject: [New-bugs-announce] [issue44724] Resource Tracker is never reaped
Message-ID: <1627046993.43.0.654405119923.issue44724@roundup.psfhosted.org>


New submission from Viktor Ivanov <viktor.ivanov at ridewithvia.com>:

The multiprocessing.resource_tracker instance is never reaped, leaving zombie processes.

There is a waitpid() call for the ResourceTracker's pid but it is in a private method _stop() which seems to be only called from some test modules.

Usually environments have some process handling zombies but if python is the "main" process in a container, for example, and runs another python instance that does something leaking a ResourceTracker process, zombies start to accumulate.

This is easily reproducible with a couple of small python programs as long as they are not run from a shell or another parent process that takes care of forgotten children.

It was originally discovered in a docker container that has a python program as its entry point (celery worker in an airflow container) running other python programs (dbt).

The minimal code is available on Github here: https://github.com/viktorvia/python-multi-issue

The attached multi.py is leaking resource tracker processes, but just running it from a full-fledged development environment will not show the issue.

Instead, run it via another python program from a Docker container:

Dockerfile:
---
FROM python:3.9

WORKDIR /usr/src/multi

COPY . ./

CMD ["python", "main.py"]
---

main.py:
---
from subprocess import run
from time import sleep

while True:
    result = run(["python", "multi.py"], capture_output=True)
    print(result.stdout.decode('utf-8'))
    result = run(["ps", "-ef", "--forest"], capture_output=True)
    print(result.stdout.decode('utf-8'), flush=True)
    sleep(1)
---

When the program is run it will accumulate 1 zombie on each run:
---
$ docker run -it multi python main.py
[1, 4, 9]

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0 11 11:33 pts/0    00:00:00 python main.py
root         8     1  0 11:33 pts/0    00:00:00 [python] <defunct>
root        17     1  0 11:33 pts/0    00:00:00 ps -ef --forest

[1, 4, 9]

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  6 11:33 pts/0    00:00:00 python main.py
root         8     1  3 11:33 pts/0    00:00:00 [python] <defunct>
root        19     1  0 11:33 pts/0    00:00:00 [python] <defunct>
root        28     1  0 11:33 pts/0    00:00:00 ps -ef --forest

[1, 4, 9]

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  4 11:33 pts/0    00:00:00 python main.py
root         8     1  1 11:33 pts/0    00:00:00 [python] <defunct>
root        19     1  3 11:33 pts/0    00:00:00 [python] <defunct>
root        30     1  0 11:33 pts/0    00:00:00 [python] <defunct>
root        39     1  0 11:33 pts/0    00:00:00 ps -ef --forest

[1, 4, 9]

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  3 11:33 pts/0    00:00:00 python main.py
root         8     1  1 11:33 pts/0    00:00:00 [python] <defunct>
root        19     1  1 11:33 pts/0    00:00:00 [python] <defunct>
root        30     1  4 11:33 pts/0    00:00:00 [python] <defunct>
root        41     1  0 11:33 pts/0    00:00:00 [python] <defunct>
root        50     1  0 11:33 pts/0    00:00:00 ps -ef --forest
---

Running from a shell script, or just another python program that handles SIGCHLD by calling wait() takes care of the zombies.

----------
components: Library (Lib)
files: multi.py
messages: 398053
nosy: viktor.ivanov
priority: normal
severity: normal
status: open
title: Resource Tracker is never reaped
type: resource usage
versions: Python 3.7, Python 3.9
Added file: https://bugs.python.org/file50173/multi.py

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

From report at bugs.python.org  Fri Jul 23 10:04:08 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 23 Jul 2021 14:04:08 +0000
Subject: [New-bugs-announce] [issue44725] Expose specialization stats in
 python
Message-ID: <1627049048.24.0.175321998203.issue44725@roundup.psfhosted.org>


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

Make it possible to fetch the current specialization stats in python so that we can compute deltas for small code snippets as well as use them for specialization unit tests.

----------
components: Interpreter Core
messages: 398055
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Expose specialization stats in python
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul 23 10:39:15 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 23 Jul 2021 14:39:15 +0000
Subject: [New-bugs-announce] [issue44726] Build macOS version with thin lto
 option
Message-ID: <1627051155.42.0.803615508224.issue44726@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

Since the thin-lto option is available for macOS distribution.
We can consider using the thin-lto option for the next macOS Python distribution?

----------
components: Build, macOS
messages: 398058
nosy: corona10, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Build macOS version with thin lto option
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul 23 11:23:37 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 23 Jul 2021 15:23:37 +0000
Subject: [New-bugs-announce] [issue44727] Stable ABI should avoid `enum`
Message-ID: <1627053817.9.0.30877505306.issue44727@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

Adding a new enumerator to a C enum can change the size of the type,
which would break the ABI.
This is not often a problem in practice, but the rules around when it is a problem and when it isn't are complicated enough that I believe enum should not be used in the stable ABI (possibly with well-reasoned exceptions)

AFAICS, the rules are:
- In C++, an incompatible change to an enum is one that changes the size of the *smallest bit field large enough to hold all enumerators*. Values outside the range cause undefined/unspecified behavior.
- In C, it looks like enums that fit in `char` are safe.

(Also, the compiler-defined size of enums will make it more cumbersome to formally define an ABI for non-C languages.)

----------
components: C API
messages: 398067
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Stable ABI should avoid `enum`

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

From report at bugs.python.org  Fri Jul 23 13:55:01 2021
From: report at bugs.python.org (Erich Eckner)
Date: Fri, 23 Jul 2021 17:55:01 +0000
Subject: [New-bugs-announce] [issue44728] Testsuite fails on x86_64
Message-ID: <1627062901.76.0.984645302952.issue44728@roundup.psfhosted.org>


New submission from Erich Eckner <python at eckner.net>:

The following tests fails on x86 32 bit:

test_cmath test_math test_posix test_turtle - looks, like the expected precision is too high.

Full log is attached.

----------
components: Tests
files: build-log.php?a=pentium4&p=python
messages: 398084
nosy: deep42thought
priority: normal
severity: normal
status: open
title: Testsuite fails on x86_64
versions: Python 3.9
Added file: https://bugs.python.org/file50175/build-log.php?a=pentium4&p=python

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

From report at bugs.python.org  Fri Jul 23 19:31:28 2021
From: report at bugs.python.org (Hasan)
Date: Fri, 23 Jul 2021 23:31:28 +0000
Subject: [New-bugs-announce] [issue44729] sys.setprofile bug
Message-ID: <1627083088.37.0.595553564439.issue44729@roundup.psfhosted.org>


New submission from Hasan <aliyevH at hotmail.com>:

1. If we try to import modules except os or sys, we will get such events. 

2. If we access frame.f_locals.items() and frame.f_code.replace() inside tracefunc, function execution shows events and stops, but if access other frame.f_locals.* it begins to call and look all files in python directory

import sys

def tracefunc(frame, event, arg):
    if event == "call":        
        print('frame.f_locals.items: ->', frame.f_locals.items())
    return tracefunc

sys.setprofile(tracefunc)


def test_sum(x: int, y: int):
    return x + y

test_sum(10, 20)

import asyncio

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

event: -> call
frame.f_locals.items: -> dict_items([('x', 10), ('y', 20)])
event: -> return
event: -> call
frame.f_locals.items: -> dict_items([('name', 'asyncio'), ('import_', <built-in function __import__>)])
event: -> call
frame.f_locals.items: -> dict_items([('self', <_frozen_importlib._ModuleLockManager object at 0x10ae2a3f0>), ('name', 'asyncio')])
event: -> return
event: -> call
frame.f_locals.items: -> dict_items([('self', <_frozen_importlib._ModuleLockManager object at 0x10ae2a3f0>)])
event: -> call
frame.f_locals.items: -> dict_items([('name', 'asyncio')])
event: -> c_call
event: -> c_return
event: -> call
frame.f_locals.items: -> Traceback (most recent call last):
  File "/Users/hasanaliyev/Documents/programming/github/test/debugger/notwork.py", line 38, in <module>
    import asyncio
    ^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1024, in _find_and_load
  File "<frozen importlib._bootstrap>", line 170, in __enter__
  File "<frozen importlib._bootstrap>", line 196, in _get_module_lock
  File "<frozen importlib._bootstrap>", line 71, in __init__
  File "/Users/hasanaliyev/Documents/programming/github/test/debugger/notwork.py", line 24, in tracefunc
    print('frame.f_locals.items: ->', frame.f_locals.items())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 139, in __repr__
AttributeError: '_ModuleLock' object has no attribute 'name'

----------
components: Library (Lib)
messages: 398102
nosy: AliyevH
priority: normal
severity: normal
status: open
title: sys.setprofile bug
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul 23 19:38:41 2021
From: report at bugs.python.org (Gareth Williams)
Date: Fri, 23 Jul 2021 23:38:41 +0000
Subject: [New-bugs-announce] [issue44730] unittest.mock.patch does not work
 as a decorator on generator functions
Message-ID: <1627083521.49.0.990756419002.issue44730@roundup.psfhosted.org>


New submission from Gareth Williams <gareth.m.j.williams at gmail.com>:

unitest.mock.patch does not work well when applied as a decorator to a function which is a generator.

It results in the function being changed from a generator function (co_flags 99) to a non-generator (co_flag 31) and the patch is not applied.

[I have a MWE, attached, and fairly simple fix, to the file mock.py, which I will put up as a PR in due course. This is the first time I've submitted a bug or PR, so apologies if I've not done this particularly well.]

----------
components: Library (Lib)
files: example_patch_failure.py
messages: 398104
nosy: garethmjwilliams
priority: normal
severity: normal
status: open
title: unittest.mock.patch does not work as a decorator on generator functions
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file50176/example_patch_failure.py

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

From report at bugs.python.org  Sat Jul 24 03:04:29 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Jul 2021 07:04:29 +0000
Subject: [New-bugs-announce] [issue44731] Simplify implementation of the
 union type
Message-ID: <1627110269.61.0.426966849087.issue44731@roundup.psfhosted.org>


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

The proposed PR simplifies implementation of the union type by removing direct support of typing types. It was not necessary because all these types implement __or__ and __ror__ methods.

The only visible difference is that int | TypeVar() etc returns now typing.Union instead of types.Union. But TypeVar() | int already returns typing.Union.

----------
components: Interpreter Core
messages: 398119
nosy: gvanrossum, kj, serhiy.storchaka, uriyyo
priority: normal
severity: normal
status: open
title: Simplify implementation of the union type
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Jul 24 05:24:20 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Jul 2021 09:24:20 +0000
Subject: [New-bugs-announce] [issue44732] Rename types.Union to
 types.UnionType
Message-ID: <1627118660.44.0.542723113695.issue44732@roundup.psfhosted.org>


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

There are differences between typing.Union and types.Union:

* typing.Union is indexable, types.Union is not.
* types.Union is a class, typing.Union is not.

types.Union corresponds to typing._UnionGenericAlias, not typing.Union. It is confusing that typing.Union and types.Union have the same name. Note also that most classes in the types module have the "Type" suffix: FunctionType, MethodType, ModuleType, etc. I think that it would be better to rename types.Union to types.UnionType.

----------
components: Interpreter Core
messages: 398128
nosy: gvanrossum, kj, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Rename types.Union to types.UnionType
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jul 24 08:14:41 2021
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 24 Jul 2021 12:14:41 +0000
Subject: [New-bugs-announce] [issue44733] Feature request: maxtasksperchild
 for ProcessPoolExecutor
Message-ID: <1627128881.56.0.324294431588.issue44733@roundup.psfhosted.org>


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

I love `concurrent.futures`, and I'd like to use it wherever I can. There's a feature in `multiprocessing.Pool` that I wish would also be available in `ProcessPoolExecutor`: The `maxtasksperchild` argument.

Documentation: "maxtasksperchild is the number of tasks a worker process can complete before it will exit and be replaced with a fresh worker process, to enable unused resources to be freed. The default maxtasksperchild is None, which means worker processes will live as long as the pool."

I want to be able to set it to 1, so each process will only execute one task and then be replaced with a fresh process.

----------
components: Library (Lib)
messages: 398143
nosy: cool-RR, pitrou
priority: normal
severity: normal
status: open
title: Feature request: maxtasksperchild for ProcessPoolExecutor
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Jul 24 12:46:47 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jul 2021 16:46:47 +0000
Subject: [New-bugs-announce] [issue44734] turtle: tests for Vec2D.__abs__
 are too strict
Message-ID: <1627145207.46.0.348646231014.issue44734@roundup.psfhosted.org>


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

>From the tests for Vec2D.__abs__ in the turtle module we have:

    def test_distance(self):
        vec = Vec2D(6, 8)
        expected = 10
        self.assertEqual(abs(vec), expected)


        vec = Vec2D(0, 0)
        expected = 0
        self.assertEqual(abs(vec), expected)


        vec = Vec2D(2.5, 6)
        expected = 6.5
        self.assertEqual(abs(vec), expected)

GitHub link: https://github.com/python/cpython/blob/8158e059e9952f08d19a18d3e9e021cee2393cd2/Lib/test/test_turtle.py#L237-L248

The first test was reported as failing in issue #44728, with error:

======================================================================
FAIL: test_distance (test.test_turtle.TestVec2D)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.6/Lib/test/test_turtle.py", line 237, in test_distance
    self.assertEqual(abs(vec), expected)
AssertionError: 9.999999999999998 != 10

The first and last test should use assertAlmostEqual with a suitable tolerance (the default tolerance is probably fine).

----------
messages: 398166
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: turtle: tests for Vec2D.__abs__ are too strict

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

From report at bugs.python.org  Sun Jul 25 01:23:58 2021
From: report at bugs.python.org (adore_blvnk)
Date: Sun, 25 Jul 2021 05:23:58 +0000
Subject: [New-bugs-announce] [issue44735] Failed venv Activation With "&" In
 Folder Name
Message-ID: <1627190638.68.0.811624039795.issue44735@roundup.psfhosted.org>


New submission from adore_blvnk <josephpoonzh at gmail.com>:

This is relating to activation of venvs. This was first discovered in VS Code, but can be replicated in Windows CMD & PyCharm too. 

Normally, creating a virtual environment via
py -m venv venv 
would create the venv.

Next would be the activation of the venv, example: 
"c:/Users/normal/venv/Scripts/activate.bat"

This activates the venv, & using a pip command would install the respective packages in the "site-packages" folder in the venv.

HOWEVER, creating a NEW folder "c:/Users/is & allowed", creating the venv, & attempting to activate it as follows:
"c:/Users/is & allowed/venv/Scripts/activate.bat"

Will throw an error:
The system cannot find the path specified.

Do note that in the 2nd attempt, the presence of character "&" will throw the error.

----------
components: Windows
messages: 398179
nosy: adore_blvnk, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Failed venv Activation With "&" In Folder Name
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Jul 25 04:50:24 2021
From: report at bugs.python.org (BAHADIR)
Date: Sun, 25 Jul 2021 08:50:24 +0000
Subject: [New-bugs-announce] [issue44736] '\t' Escape Sequence behaving
 differently.
Message-ID: <1627203024.75.0.177419132701.issue44736@roundup.psfhosted.org>


New submission from BAHADIR <b123qweasdzxc at gmail.com>:

While working on several examples I noticed that ASCII Horizontal Tab (TAB) gives different results for different values. When I looked at the rfc documents, I couldn't see any result about its calculation. The calculation method I noticed myself is as follows ((8 -(string from previous "\t"))%8) * a number of spaces(in python IDLE) result change in other IDE or editors.

----------
components: Parser
messages: 398180
nosy: BAHADIR, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: '\t' Escape Sequence behaving differently.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Jul 25 23:51:36 2021
From: report at bugs.python.org (Du)
Date: Mon, 26 Jul 2021 03:51:36 +0000
Subject: [New-bugs-announce] [issue44737] Mapping from to collections.abc
Message-ID: <1627271496.93.0.602313115544.issue44737@roundup.psfhosted.org>


New submission from Du <491609917 at qq.com>:

When using Sanic, referencing Mapping in collections in SANic-Jinja2 brings ImportError: Cannot import name 'Mapping' from 'collections'. When you use Mapping, shouldn't you call from collections.abc?

----------
messages: 398208
nosy: haitanghuadeng
priority: normal
severity: normal
status: open
title: Mapping from to collections.abc
type: resource usage
versions: Python 3.10

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

From report at bugs.python.org  Mon Jul 26 03:49:50 2021
From: report at bugs.python.org (Joongi Kim)
Date: Mon, 26 Jul 2021 07:49:50 +0000
Subject: [New-bugs-announce] [issue44738] io_uring as a new backend to
 selectors and asyncio
Message-ID: <1627285790.87.0.178288680058.issue44738@roundup.psfhosted.org>


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

This is a rough early idea suggestion on adding io_uring as an alternative I/O multiplexing mechanism in Python (maybe selectors and asyncio). io_uring is a relatively new I/O mechanism introduced in Linux kernel 5.1 or later.

https://lwn.net/Articles/776703/
https://lwn.net/Articles/810414/
https://blogs.oracle.com/linux/post/an-introduction-to-the-io_uring-asynchronous-io-framework

The advantages of io_uring over epoll:
 - completion-based
 - less number of syscalls
 - higher performance (https://twitter.com/hielkedv/status/1218891982636027905)
 - file I/O support including read/write/stat/open/close

I'm not sure that io_uring would bring actual performance improvements to Python (and asyncio) or not yet.
We need some exploration and prototyping, but still technically it would be a nice-to-have feature, considering Python's recent speed-up optimizations.
Also io_uring is also intended to support high-speed storage devices such as NVMe, and may be a good addition to asyncio in terms of improved async file I/O support.

Here are existing attempts to incorporate uring in other languages:
 - liburing (C, https://github.com/axboe/liburing)
 - iou, tokio-uring (Rust, https://tokio.rs/blog/2021-07-tokio-uring)

I don't have any estimation on the efforts and time required to do the work,
but just want to spark the discussion. :)

----------
components: asyncio
messages: 398215
nosy: achimnol, asvetlov, corona10, njs, yselivanov
priority: normal
severity: normal
status: open
title: io_uring as a new backend to selectors and asyncio
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Jul 26 07:16:21 2021
From: report at bugs.python.org (logon_name)
Date: Mon, 26 Jul 2021 11:16:21 +0000
Subject: [New-bugs-announce] [issue44739] XScrollbar is not stationary
Message-ID: <1627298181.72.0.462970304554.issue44739@roundup.psfhosted.org>


New submission from logon_name <yao352698 at 163.com>:

Hello!
When I was working on Tkinter GUI, I made a Text with two Scrollbars. But when I created many lines, filled the last line with letters, and then dragged the YScrollbar upwards, the XScrollbar could not be dragged. Moreover, when dragging down to the end, the Slider of the XScrollbar is not on the far right.
I hope this bug can be fixed as soon as possible.

----------
components: Tkinter
files: editor.py
messages: 398221
nosy: logon_name
priority: normal
severity: normal
status: open
title: XScrollbar is not stationary
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50181/editor.py

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

From report at bugs.python.org  Mon Jul 26 07:52:23 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Mon, 26 Jul 2021 11:52:23 +0000
Subject: [New-bugs-announce] [issue44740] Lowercase "Internet" and "web" in
 docs
Message-ID: <1627300343.54.0.087509500889.issue44740@roundup.psfhosted.org>


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

AP lowercased "internet" and "web" in all instances ? web page, the web, web browser, etc. on June 1, 2016:

https://twitter.com/APStylebook/status/716384777406922753
https://twitter.com/APStylebook/status/716279539052191746?s=20

I'd be happy to provide a patch, if accepted.

We will update the Django docs to follow this recommendation, see https://code.djangoproject.com/ticket/32956.

----------
assignee: docs at python
components: Documentation
messages: 398223
nosy: docs at python, felixxm
priority: normal
severity: normal
status: open
title: Lowercase "Internet" and "web" in docs
type: enhancement

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

From report at bugs.python.org  Mon Jul 26 10:23:39 2021
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 26 Jul 2021 14:23:39 +0000
Subject: [New-bugs-announce] [issue44741] Pattern Matching - star subpattern
 with a subject derived from collections.abc.Sequence
Message-ID: <1627309419.51.0.550971310919.issue44741@roundup.psfhosted.org>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

This code

    match range(42):
        case [x, *w, y]:
            z = 0

sets w to a list with 40 items : the length of the subject, minus the number of non-star subpatterns.

But this code (adapted from test_patma_186) enters an infinite loop

    import collections.abc

    class Seq(collections.abc.Sequence):
        def __getitem__(self, i):
            print('get item', i)
            return i
        def __len__(self):
            return 42

    match Seq():
        case [x, *w, y]:
            z = 0

__getitem__ gets called forever, instead of stopping when the expected number of items in w is reached.

----------
components: Interpreter Core
messages: 398226
nosy: quentel
priority: normal
severity: normal
status: open
title: Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence
type: crash
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Jul 26 10:39:49 2021
From: report at bugs.python.org (=?utf-8?q?C=C3=A9lestin_Matte?=)
Date: Mon, 26 Jul 2021 14:39:49 +0000
Subject: [New-bugs-announce] [issue44742] smtplib: less confusing behaviour
 when giving incorrect multiple recipients list
Message-ID: <1627310389.11.0.324785663075.issue44742@roundup.psfhosted.org>


New submission from C?lestin Matte <python at cmatte.me>:

When giving recipients in a string format ("email1, email2") to sendmail(), an email is sent to the first email in the list only.
This is not a bug since the documentation indicates that sendmail() takes either a list of addresses, or a single address in a string. However, this error is easy to make since the "To:" field expects a comma-separated series of email addresses in a string format.

I suggest either that:
- sendmail() accepts a series of emails in a string format: "email1, email2" for the recipient lists
- sendmail() raises an exception if a series of email in a string format is detected

Attached is an example script to test confusing behaviour (email is sent to email1 at mydomain.com only):

----------
files: test_sendmail.py
messages: 398228
nosy: cmatte
priority: normal
severity: normal
status: open
title: smtplib: less confusing behaviour when giving incorrect multiple recipients list
type: enhancement
Added file: https://bugs.python.org/file50182/test_sendmail.py

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

From report at bugs.python.org  Mon Jul 26 10:50:58 2021
From: report at bugs.python.org (Julian_Orteil)
Date: Mon, 26 Jul 2021 14:50:58 +0000
Subject: [New-bugs-announce] [issue44743] asyncio DatagramProtocol stops
 calling callbacks after OSError
Message-ID: <1627311058.63.0.328526216812.issue44743@roundup.psfhosted.org>


New submission from Julian_Orteil <dakota.horstman2001 at gmail.com>:

After working through the Transports and Protocols documentation of asyncio, I decided to stress test the DatagramProtocol as an application I'm developing needs to act as a UDP server.

One of my tests drops the client before the server responds which raises an OSError on the server; however, after the error is raised, the server stops executing callbacks (like connection_made, datagram_received, error_received and connection_lost) until it is restarted. There is no documentation I can find that explains this behavior nor is there any meaningful discussions about it elsewhere. I don't think the socket itself drops because the client doesn't raise an OSError itself when connecting to the now-errored server.

Interestingly though, when I tried to enable debug mode of the loops on both the client to see if there were any silent errors being raised (which didn't occur), this issue doesn't occur. Enabling debug mode on the server had no effect.

Attached is the reproducible code; it is a slightly modified version of the UDP Echo Client/Server example found in the docs named above. My environment is Python 3.9.5 on Windows 10.

----------
components: asyncio
files: reproducible_datagramprotocol_error.py
messages: 398229
nosy: JulianOrteil, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio DatagramProtocol stops calling callbacks after OSError
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50183/reproducible_datagramprotocol_error.py

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

From report at bugs.python.org  Mon Jul 26 10:58:32 2021
From: report at bugs.python.org (ready-research)
Date: Mon, 26 Jul 2021 14:58:32 +0000
Subject: [New-bugs-announce] [issue44744] [security] Open redirect attack
 due to insufficient validation in Urlparse
Message-ID: <1627311512.81.0.173431010416.issue44744@roundup.psfhosted.org>


New submission from ready-research <readyresearchsec at gmail.com>:

`urlparse` mishandles certain uses of extra slash or backslash(such as https:/// , https:/, https:\) and interprets the URI as a relative path. 

A userland logic implementation that bases its decision on the urlparse() function may introduce a security vulnerability due to the unexpected returned values of the function. These vulnerabilities may manifest as an SSRF, Open Redirect, and other types of vulnerabilities related to incorrectly trusting a URL.

```
from urllib.parse import urlparse
url1=urlparse('https://www.attacker.com/a/b')
url2=urlparse('https:///www.attacker.com/a/b')
url3=urlparse('https:/www.attacker.com/a/b')
url4=urlparse('https:\www.attacker.com/a/b')
print("Normal behaviour: HOSTNAME should be in netloc\n")
print(url1)
print("\nMishandling hostname and returning it as path\n")
print(url2)
print(url3)
print(url4)
```

OUTPUT:
```
Normal behaviour: HOSTNAME should be in netloc

ParseResult(scheme='https', netloc='www.attacker.com', path='/a/b', params='', query='', fragment='')

Mishandling hostname and returning it as path

ParseResult(scheme='https', netloc='', path='/www.attacker.com/a/b', params='', query='', fragment='')
ParseResult(scheme='https', netloc='', path='/www.attacker.com/a/b', params='', query='', fragment='')
ParseResult(scheme='https', netloc='', path='\\www.attacker.com/a/b', params='', query='', fragment='')
```

----------
components: Parser
messages: 398232
nosy: lys.nikolaou, pablogsal, ready-research
priority: normal
severity: normal
status: open
title: [security] Open redirect attack due to insufficient validation in Urlparse
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jul 26 18:09:14 2021
From: report at bugs.python.org (Matthew Zielinski)
Date: Mon, 26 Jul 2021 22:09:14 +0000
Subject: [New-bugs-announce] [issue44745] Manual for python 3.9.6 will not
 let me search
Message-ID: <1627337354.47.0.497539026172.issue44745@roundup.psfhosted.org>


New submission from Matthew Zielinski <matthman2019 at gmail.com>:

The Manual for python 3.9.6 always says there are no entries. I searched things it definitely had, like modules, but it said there were no topics found.

----------
components: Library (Lib)
files: Python Error.png
messages: 398261
nosy: matthman2019
priority: normal
severity: normal
status: open
title: Manual for python 3.9.6 will not let me search
type: resource usage
versions: Python 3.9
Added file: https://bugs.python.org/file50184/Python Error.png

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

From report at bugs.python.org  Tue Jul 27 02:49:22 2021
From: report at bugs.python.org (Priyanshu)
Date: Tue, 27 Jul 2021 06:49:22 +0000
Subject: [New-bugs-announce] [issue44746] Improper behaviour of 'finally'
 keyword
Message-ID: <1627368562.8.0.609178233641.issue44746@roundup.psfhosted.org>


New submission from Priyanshu <priyanshu_ug at mech.nits.ac.in>:

The finally clause is not executed when an exception occurs and 'raise' keyword is used in except clause.

----------
components: Windows
messages: 398278
nosy: Priyanshu, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Improper behaviour of 'finally' keyword
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 27 05:04:49 2021
From: report at bugs.python.org (Yurii Karabas)
Date: Tue, 27 Jul 2021 09:04:49 +0000
Subject: [New-bugs-announce] [issue44747] Reduce usage of sys._getframe at
 typing module
Message-ID: <1627376689.96.0.280713555823.issue44747@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

While I was working with `typing` I have notice that there are duplication of `_getframe` usage. While In scope of issue 44353 I introduced `typing._callee` function which allow to return module name of a caller function.

In scope of this issue we will reduce the usage of `_getframe` usage. It will be used only in one place, at `_callee` function.

----------
components: Library (Lib)
messages: 398286
nosy: uriyyo
priority: normal
severity: normal
status: open
title: Reduce usage of sys._getframe at typing module
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 27 05:26:32 2021
From: report at bugs.python.org (Thermi)
Date: Tue, 27 Jul 2021 09:26:32 +0000
Subject: [New-bugs-announce] [issue44748] argparse: a bool indicating if arg
 was encountered
Message-ID: <1627377992.52.0.310829281762.issue44748@roundup.psfhosted.org>


New submission from Thermi <noel.kuntze+bugs-python-org at thermi.consulting>:

It'd be great if as part of the namespace returned by argparse.ArgumentParser.parse_args(), there was a bool indicating if a specific argument was encountered.

That could then be used to implement the following behaviour:
With a config file loaded as part of the program, overwrite the values loaded from the config file if the argument was encountered in the argument vector.

That's necessary to implement overwriting of settings that were previously set by a different mechanism, e.g. read from a config file.

After all the following order of significance should be used:
program defaults < config file < argument vector

----------
components: Library (Lib)
messages: 398288
nosy: Thermi
priority: normal
severity: normal
status: open
title: argparse: a bool indicating if arg was encountered
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jul 27 10:13:35 2021
From: report at bugs.python.org (Douglas Raillard)
Date: Tue, 27 Jul 2021 14:13:35 +0000
Subject: [New-bugs-announce] [issue44749] LOAD_NAME not using
 PyObject_GetItem when globals() is a dict subclass
Message-ID: <1627395215.45.0.945166676554.issue44749@roundup.psfhosted.org>


New submission from Douglas Raillard <douglas.raillard at arm.com>:

Re-raising the bug reported by Kevin Shweh:
thread: https://bugs.python.org/issue14385
message: https://bugs.python.org/msg337245

Here is a copy for easier reference:

The patch for this issue changed LOAD_GLOBAL to use PyObject_GetItem when globals() is a dict subclass, but LOAD_NAME, STORE_GLOBAL, and DELETE_GLOBAL weren't changed. (LOAD_NAME uses PyObject_GetItem for builtins now, but not for globals.)

This means that global lookup doesn't respect overridden __getitem__ inside a class statement (unless you explicitly declare the name global with a global statement, in which case LOAD_GLOBAL gets used instead of LOAD_NAME).

I don't have a strong opinion on whether STORE_GLOBAL or DELETE_GLOBAL should respect overridden __setitem__ or __delitem__, but the inconsistency between LOAD_GLOBAL and LOAD_NAME seems like a bug that should be fixed.

For reference, in the following code, the first 3 exec calls successfully print 5, and the last exec call fails, due to the LOAD_GLOBAL/LOAD_NAME inconsistency:

class Foo(dict):
    def __getitem__(self, index):
        return 5 if index == 'y' else super().__getitem__(index)
 
exec('print(y)', Foo())
exec('global y; print(y)', Foo())
exec('''
class UsesLOAD_NAME:
    global y
    print(y)''', Foo())
exec('''
class UsesLOAD_NAME:
    print(y)''', Foo())


I encountered the same issue when trying to create a way to "instantiate" modules with some globals replaced by user-defined values to make a dependency-injection system. I therefore want to lookup some names in a separate dict rather than getting the value normally bound in that module (typically by an import statement).

----------
components: Interpreter Core
messages: 398299
nosy: douglas-raillard-arm
priority: normal
severity: normal
status: open
title: LOAD_NAME not using PyObject_GetItem when globals() is a dict subclass
versions: Python 3.10

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

From report at bugs.python.org  Tue Jul 27 13:35:28 2021
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 27 Jul 2021 17:35:28 +0000
Subject: [New-bugs-announce] [issue44750] .popitem() is inconsistent in
 collections and collections.abc
Message-ID: <1627407328.07.0.937784840037.issue44750@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

In a Python dictionary, `.popitem()` returns (key, value) pairs from the dictionary in a LIFO order. `collections.OrderedDict` and `collections.Counter` both do the same. However, a class inheriting from `collections.abc.MutableMapping` (which includes, in the standard library, `collections.UserDict`), will inherit a `.popitem()` method that returns (key, value) pairs in a FIFO order.

In my opinion, this seems like unexpected behaviour, given that these classes are designed to emulate the API of a standard Python dict.

The documentation for ordinary dictionaries states that `.popitem()` uses LIFO (https://docs.python.org/3/library/stdtypes.html#typesmapping), as does `collections.OrderedDict` (https://docs.python.org/3/library/collections.html#collections.OrderedDict). However, I can't find anything in the documentation for the collections.abc module (https://docs.python.org/3/library/collections.abc.html) or the docstring for `collections.abc.MutableMapping.popitem()` (https://github.com/python/cpython/blob/ae0a2b756255629140efcbe57fc2e714f0267aa3/Lib/_collections_abc.py#L964) that states that collections.abc.MutableMapping will use FIFO. Ditto for the collections.UserDict documentation/docstring: https://docs.python.org/3/library/collections.html#collections.UserDict, https://github.com/python/cpython/blob/6948964ecf94e858448dd28eea634317226d2913/Lib/collections/__init__.py#L1084.

Is this expected/intended behaviour? I found it highly confusing when attempting to implement a custom data structure just now. I think a note in the docstring/documentation, noting that this is the behaviour, would certainly be useful.

I have attached a minimal demonstration of this behaviour. Tests only done on Python 3.9.

----------
components: Library (Lib)
files: collections popitem weirdness.py
messages: 398310
nosy: AlexWaygood
priority: normal
severity: normal
status: open
title: .popitem() is inconsistent in collections and collections.abc
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50187/collections popitem weirdness.py

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

From report at bugs.python.org  Tue Jul 27 17:23:37 2021
From: report at bugs.python.org (Geoffrey Thomas)
Date: Tue, 27 Jul 2021 21:23:37 +0000
Subject: [New-bugs-announce] [issue44751] crypt.h should be in
 _cryptmodule.c, not in public header
Message-ID: <1627421017.82.0.756095200608.issue44751@roundup.psfhosted.org>


New submission from Geoffrey Thomas <geofft at ldpreload.com>:

In #32635, it was discovered that _cryptmodule.c was missing a dependency on crypt.h, which caused it to segfault when it was missing the proper prototype for crypt. This was fixed by adding an #include <crypt.h> to Python.h.

This include doesn't need to be in the public header; it only needs to be in _cryptmodule.c. Removing it from the public header is helpful for packagers, because it means that the libpython-dev (or whatever) package doesn't need a dependency on libcrypt-dev, only on the libcrypt runtime library.

----------
components: C API
messages: 398321
nosy: geofft
priority: normal
severity: normal
status: open
title: crypt.h should be in _cryptmodule.c, not in public header
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jul 27 17:41:47 2021
From: report at bugs.python.org (Ryan Pecor)
Date: Tue, 27 Jul 2021 21:41:47 +0000
Subject: [New-bugs-announce] [issue44752] Tab completion executes @property
 getter function
Message-ID: <1627422107.77.0.358238210778.issue44752@roundup.psfhosted.org>


New submission from Ryan Pecor <ryan at pecor.com>:

After making a class using the @property decorator to implement a getter, using tab completion that matches the getter function name executes the function. 

See below for example (line numbers added, <tab> indicates when the user presses the tab key):

1  >>> class Foo(object):
2  ...     def __init__(self,value):
3  ...         self.value = value
4  ...     @property
5  ...     def print_value(self):
6  ...         print("Foo has a value of {}".format(self.value))
7  ... 
8  >>> bar = Foo(4)
9  >>> bar.<tab>~~~Foo has a value of 4~~~
10 <tab>~~~Foo has a value of 4~~~
11 
12 bar.print_value  bar.value        
13 >>> bar.p<tab>~~~Foo has a value of 4~~~
14 <tab>rint_value~~~Foo has a value of 4~~~
15 ~~~Foo has a value of 4~~~
16 
17 bar.print_value
18 >>> bar.v<tab>alue

I pressed tab after typing "bar." in line 9. It then printed the remainder of line 9 and moved the cursor to line 10. Pressing tab again prints line 10 and 11 before finally showing the expected output on line 12. lines 13-17 follow the same steps, but after typing "bar.p" to show that it happens whenever you tab and it matches the getter. Line 18 shows a correct tab completion resulting from hitting tab after typing "bar.v" which does not match the getter function.

----------
components: Interpreter Core
messages: 398323
nosy: RPecor
priority: normal
severity: normal
status: open
title: Tab completion executes @property getter function
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 27 18:37:55 2021
From: report at bugs.python.org (Alexander Smirnov)
Date: Tue, 27 Jul 2021 22:37:55 +0000
Subject: [New-bugs-announce] [issue44753] backupCount is not respected in
 TimedRotatingFileHandler when namer is specified
Message-ID: <1627425475.0.0.681821492357.issue44753@roundup.psfhosted.org>


New submission from Alexander Smirnov <alexander.smirnoff at gmail.com>:

after adding namer callable (like it is described in https://bugs.python.org/issue43344) to log handler configuration, it stopped removing old files

log_filename = os.path.join(log_dir, "application.log")
log_handler = logging.handlers.TimedRotatingFileHandler(log_filename, when='MIDNIGHT', interval=1, backupCount=7)

// after adding this line, old files are not deleted
log_handler.namer = lambda name: name.replace(".log", "") + ".log"

----------
components: Library (Lib)
messages: 398326
nosy: alexander.smirnoff
priority: normal
severity: normal
status: open
title: backupCount is not respected in TimedRotatingFileHandler when namer is specified
versions: Python 3.8

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

From report at bugs.python.org  Tue Jul 27 19:23:07 2021
From: report at bugs.python.org (Mark Gluzman)
Date: Tue, 27 Jul 2021 23:23:07 +0000
Subject: [New-bugs-announce] [issue44754] Documentation for pop in Built-in
 Types
Message-ID: <1627428187.16.0.834558477955.issue44754@roundup.psfhosted.org>


New submission from Mark Gluzman <mg2289 at cornell.edu>:

Python documentation: v.3.9.6 
The Python Standard Library >> Built-in Types >> Mutable Sequence Types

The table says that 'pop' operation should be written as 
s.pop([i]) 

The right way to do it is 
s.pop(i)

----------
assignee: docs at python
components: Documentation
messages: 398329
nosy: docs at python, mark-gluzman
priority: normal
severity: normal
status: open
title: Documentation for pop in Built-in Types
versions: Python 3.9

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

From report at bugs.python.org  Tue Jul 27 21:05:16 2021
From: report at bugs.python.org (David Duffy)
Date: Wed, 28 Jul 2021 01:05:16 +0000
Subject: [New-bugs-announce] [issue44755] cpython Lib bisect.py overflow (lo
 + hi) // 2 a problem?
Message-ID: <1627434316.29.0.740067816285.issue44755@roundup.psfhosted.org>


New submission from David Duffy <David.Duffy at qimr.edu.au>:

https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html

led me to change to lo+(lo+hi)/2 - would this affect bisect.py???

----------
components: Library (Lib)
messages: 398337
nosy: David.Duffy
priority: normal
severity: normal
status: open
title: cpython Lib bisect.py overflow  (lo + hi) // 2 a problem?
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Jul 28 00:47:26 2021
From: report at bugs.python.org (Jack DeVries)
Date: Wed, 28 Jul 2021 04:47:26 +0000
Subject: [New-bugs-announce] [issue44756] In ./Doc,
 "make html" and "make build" should depend on "make venv"
Message-ID: <1627447646.0.0.0697423351064.issue44756@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

In Doc/Makefile, all of the build rules should be dependent on the existence of a virtual environment. I could see this being controversial, because folks who have these tools installed elsewhere might prefer not to have a venv made for them, but my personal workflow is to strive to keep my system site-packages folder as empty as possible and to use virtual environments frequently. In any case, I'm interested to hear what we think.

Momentarily, I will attach a PR where I went ahead and made these changes. Here is a summary of the changes:

- venv rule is now conditional, and only does anything if $VENVDIR does 
  not exist
- add rule "clean-venv". This can be removed ??what do you all think?
- build rule is dependent on venv
- as a result, rules dependent on build are dependent on venv
  - html
  - latex
  - etc.
- update Doc/README.rst appropriately. Now users only need to type 
  ``make html`` ??nice!

Let me know what you think. I may have a blind spot to others' workflows! Also, I'm not a Windows user, so I have no insight as to whether ``make.bat`` needs to be updated as well.

----------
assignee: docs at python
components: Demos and Tools, Documentation
messages: 398344
nosy: docs at python, jack__d
priority: normal
severity: normal
status: open
title: In ./Doc, "make html" and "make build" should depend on "make venv"
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul 28 02:37:24 2021
From: report at bugs.python.org (=?utf-8?b?8J+WpEJsYWNrIEpva2Vy8J+WpA==?=)
Date: Wed, 28 Jul 2021 06:37:24 +0000
Subject: [New-bugs-announce] [issue44757] Insecure Deserialization
Message-ID: <1627454244.04.0.843143587148.issue44757@roundup.psfhosted.org>


New submission from ?Black Joker? <akki.dw007 at gmail.com>:

There are a number of techniques for reading external files and loading their content into (de/serializing) Python objects. Pickle is one such powerful serialization technique that is inherently risky, especially when an attacker tampers with serialized data.

Data from external sources is never secure. As a rule of thumb, never unpickle or parse data from an untrusted source into Python objects. This is because an attacker can use a subprocess module to execute arbitrary commands during pickling.

Additionally, YAML files from user input can leave your application open to attacks. To avoid this, use PyYAML safe_loadfunction (yaml.safe_load) to handle YAML serialization.

Here is a simple custom code that can be used to find all unsafe yaml.load functions in your codebase.

----------
components: Tests
messages: 398347
nosy: joker
priority: normal
severity: normal
status: open
title: Insecure Deserialization
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 28 03:37:45 2021
From: report at bugs.python.org (Antel)
Date: Wed, 28 Jul 2021 07:37:45 +0000
Subject: [New-bugs-announce] [issue44758] Why " True != 3 in [3] " is True?
Message-ID: <1627457865.31.0.843205234519.issue44758@roundup.psfhosted.org>


New submission from Antel <410828726 at qq.com>:

>>> (True != 3) in [3]
False
>>> True != (3 in [3])
False

>>> True != 3 in [3]
True

----------
components: Tests
messages: 398354
nosy: Antelx
priority: normal
severity: normal
status: open
title: Why " True != 3 in [3] "  is True?
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul 28 04:55:12 2021
From: report at bugs.python.org (=?utf-8?q?Stephan_B=C3=B6kelmann?=)
Date: Wed, 28 Jul 2021 08:55:12 +0000
Subject: [New-bugs-announce] [issue44759] ctype generates misleading
 error-msg opening lib.so when compiled for wrong arch
Message-ID: <1627462512.53.0.0502908883439.issue44759@roundup.psfhosted.org>


New submission from Stephan B?kelmann <stephan.boekelmann at gruppe.ai>:

When trying to open a lib.so that has been compiled for a different architecture an error-msg is emitted saying. "no such file or directory" 

this is misleading behavior. changing the error-msg to. "library not compatible with architecture" would have saved me an hour of work ;)

----------
components: ctypes
messages: 398357
nosy: stephan.boekelmann
priority: normal
severity: normal
status: open
title: ctype generates misleading error-msg opening lib.so when compiled for wrong arch
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul 28 05:31:01 2021
From: report at bugs.python.org (Ray Kinane)
Date: Wed, 28 Jul 2021 09:31:01 +0000
Subject: [New-bugs-announce] [issue44760] Turtle Documentation - Contents
 Hyperlink conflict
Message-ID: <1627464661.57.0.766056732309.issue44760@roundup.psfhosted.org>


New submission from Ray Kinane <raykinane at gmail.com>:

In the Turtle module,
there are 2 methods named "clear",
one for turtle objects and one for screen objects.

In the Turtle module documentation, 
in the contents section, 
in the "Turtle methods" section, 
under "More drawing control"
the clear() method hyperlink 
does not point to the correct section in the article.
It points to the section for the clear method for screen objects.

There is another identical hyperlink issue in the same article due to 2 methods with the same name: "reset"

----------
assignee: docs at python
components: Documentation
messages: 398361
nosy: docs at python, ray_giraffe
priority: normal
severity: normal
status: open
title: Turtle Documentation - Contents Hyperlink conflict
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 28 06:06:10 2021
From: report at bugs.python.org (Yurii Karabas)
Date: Wed, 28 Jul 2021 10:06:10 +0000
Subject: [New-bugs-announce] [issue44761] NewType __module__ name
Message-ID: <1627466770.61.0.0184173435686.issue44761@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

This issue related to https://bugs.python.org/issue44353

By default `__module__` attribute of a `NewType` is set to "typing" but in other typing classes it set to "__main__".

----------
components: Library (Lib)
messages: 398365
nosy: kj, uriyyo
priority: normal
severity: normal
status: open
title: NewType __module__ name
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jul 28 09:08:08 2021
From: report at bugs.python.org (jan matejek)
Date: Wed, 28 Jul 2021 13:08:08 +0000
Subject: [New-bugs-announce] [issue44762] getpass.getpass on Windows
 fallback detection is bad
Message-ID: <1627477688.83.0.954525196129.issue44762@roundup.psfhosted.org>


New submission from jan matejek <ja+python at matejcik.cz>:

The fallback detection for `win_getpass` checks that `sys.stdin` is different from `sys.__stdin__`. If yes, it assumes that it's incapable of disabling echo, and calls `default_getpass` which reads from stdin.

If they are the same object, it assumes it's in a terminal and uses `msvcrt` to read characters.

I was not able to find any rationale for this check, it seems to have been introduced, oh wow, in 2001, to fix something IDLE-related.

Anyway, the check is trivially incorrect. It fails when such script is launched from `subprocess.Popen(stdin=PIPE)`, where both `sys.stdin` and `sys.__stdin__` are the same instance of `TextIOWrapper`. Same actually happens in MinTTY (Git Bash etc.) which is not a true terminal as far as I was able to find out?

It seems that a better check would be, e.g., `sys.stdin.isatty()`, which correctly returns `False` both in subprocesses and in MinTTY.

----------
components: Library (Lib)
messages: 398370
nosy: matejcik
priority: normal
severity: normal
status: open
title: getpass.getpass on Windows fallback detection is bad
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 28 10:56:18 2021
From: report at bugs.python.org (Jack DeVries)
Date: Wed, 28 Jul 2021 14:56:18 +0000
Subject: [New-bugs-announce] [issue44763] "width defaults to 70." in
 textwrap.wrap documentation is repetitive.
Message-ID: <1627484178.54.0.800781204335.issue44763@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

The phrase "width defaults to 70." in the documentation for textwrap.wrap is repetitive, because that information is already communicated in the function signature.

The desire to fix this came up this discussion around this PR:
https://github.com/python/cpython/pull/26999#discussion_r678322870

I will attach a PR momentarily.

----------
assignee: docs at python
components: Documentation
messages: 398392
nosy: docs at python, jack__d
priority: normal
severity: normal
status: open
title: "width defaults to 70." in textwrap.wrap documentation is repetitive.
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul 28 12:18:43 2021
From: report at bugs.python.org (Ilian Iliev)
Date: Wed, 28 Jul 2021 16:18:43 +0000
Subject: [New-bugs-announce] [issue44764] Handling interruption in async
 tasks
Message-ID: <1627489123.42.0.553634869406.issue44764@roundup.psfhosted.org>


New submission from Ilian Iliev <ilian at ilian.io>:

The idea is to provide a way for graceful shutdown so that if an interruption occurs all async tasks are given a certain time to finish before we exit the process.

Please take a look at the provided example -> https://gist.github.com/IlianIliev/9aba04a74a4faddf0749533205d3b001

If the interruption happens during an await (if we use `await asyncio.sleep(5)`), all works correctly. The exception is raised to the root level and we do the graceful shutdown on line 37.

But if the interruption happens during a normal execution (`time.sleep()`) it is raised at the currently running line and this way breaks the function without any chances or recovery. 
While `time.sleep` is not that widely used, the same problem occurs if we have any other long-running code e.g. iterating over a big list.

This was found while looking for a way to provide a graceful shutdown for the grpcio server -> https://github.com/grpc/grpc/issues/26123

Is it possible to change the behaviour so the exception is raised on a higher level when sync tasks are executed in async context?

----------
hgrepos: 407
messages: 398400
nosy: ilian
priority: normal
severity: normal
status: open
title: Handling interruption in async tasks
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 28 13:55:24 2021
From: report at bugs.python.org (Eesa Ibrahim Khokhar)
Date: Wed, 28 Jul 2021 17:55:24 +0000
Subject: [New-bugs-announce] [issue44765] Misspelled Word In Docs
Message-ID: <1627494924.73.0.555225161539.issue44765@roundup.psfhosted.org>


New submission from Eesa Ibrahim Khokhar <khokhareesa.home at gmail.com>:

Quote Official docs:
"For e.g. server can **chose** to send 417 Expectation Failed as a response header and return False."
Above, choose is misspelled.

----------
messages: 398410
nosy: khokhareesa.home
priority: normal
severity: normal
status: open
title: Misspelled Word In Docs

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

From report at bugs.python.org  Wed Jul 28 14:07:12 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 28 Jul 2021 18:07:12 +0000
Subject: [New-bugs-announce] [issue44766] [easy doc] Remove redundant info
 in README.valgrind
Message-ID: <1627495632.91.0.703562512799.issue44766@roundup.psfhosted.org>


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

Objects/obmalloc.c hasn't use the Py_USING_MEMORY_DEBUGGER macro now. So this line can be deleted.
https://github.com/python/cpython/blob/31bec6f1b178dadec3cb43353274b4e958a8f015/Misc/README.valgrind#L17.

----------
assignee: docs at python
components: Documentation
messages: 398411
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: [easy doc] Remove redundant info in README.valgrind
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jul 28 14:46:29 2021
From: report at bugs.python.org (Chandrakant Naik)
Date: Wed, 28 Jul 2021 18:46:29 +0000
Subject: [New-bugs-announce] [issue44767] python -m flask run gives OSError:
 [WinError 10013] An attempt was made to access a socket in a way forbidden
 by its access permissions
Message-ID: <1627497989.44.0.166759062012.issue44767@roundup.psfhosted.org>


New submission from Chandrakant Naik <chandrakant.rvce at gmail.com>:

Attached is teh app.py program. I tried runnign it in VS Code via the cmd - python -m flask run. It gives me the below error 

OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

Tried changing the port and executing it still no luck

----------
components: Library (Lib)
files: app.py
messages: 398413
nosy: Jimbofbx, chandrakant.rvce, loewis, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: python -m flask run gives OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50189/app.py

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

From report at bugs.python.org  Wed Jul 28 16:42:31 2021
From: report at bugs.python.org (pavel-lexyr)
Date: Wed, 28 Jul 2021 20:42:31 +0000
Subject: [New-bugs-announce] [issue44768] dataclasses.dataclass and
 collections.namedtuple do the same thing
Message-ID: <1627504951.63.0.727220170445.issue44768@roundup.psfhosted.org>


New submission from pavel-lexyr <pavel at lexyr.com>:

PEP 20 states:

> There should be one-- and preferably only one --obvious way to do it.

As of right now, two very similar constructions for making a lightweight dataclass exist in Python.

collections.namedtuple is one of them. dataclasses.dataclass is the other*.

The behaviour they provide is very similar. And with the functions .astuple() and the `frozen` constructor argument of the dataclass, one could consider it to be almost a direct superset of the namedtuple.


Having two different classes with very similar behaviour is not considered a good practice. I propose merging the two classes' features into one and to deprecate the other, to prevent unnecessary ambiguity.


* To get deeper into semantics, we might consider types.SimpleNamespace to be the third. This is out of this issue's scope - the reader is welcome to follow up in another one.

----------
components: Library (Lib)
messages: 398421
nosy: eric.smith, pavel-lexyr, rhettinger
priority: normal
severity: normal
status: open
title: dataclasses.dataclass and collections.namedtuple do the same thing
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jul 28 17:32:39 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 28 Jul 2021 21:32:39 +0000
Subject: [New-bugs-announce] [issue44769] socketserver.shutdown should stop
 serve_forever() immediately
Message-ID: <1627507959.35.0.467924205833.issue44769@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

Currently, socketserver.serve_forever() sets a variable and serve_forever() polls for it, with a configurable interval.

A comment in the code already says:
# XXX: Consider using another file descriptor or connecting to the
# socket to wake this up instead of polling. Polling reduces our
# responsiveness to a shutdown request and wastes cpu at all other
# times.

----------
components: Library (Lib)
messages: 398427
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: socketserver.shutdown should stop serve_forever()  immediately

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

From report at bugs.python.org  Wed Jul 28 21:06:36 2021
From: report at bugs.python.org (Marty)
Date: Thu, 29 Jul 2021 01:06:36 +0000
Subject: [New-bugs-announce] [issue44770] float('nan') is True
Message-ID: <1627520796.5.0.36513663962.issue44770@roundup.psfhosted.org>


New submission from Marty <vpjtqwv0101 at gmail.com>:

I know that there is numpy.isnan() for checking if a value is float('nan') but I think that native python should logically return False in bool(float('nan')).

----------
messages: 398448
nosy: vpjtqwv0101
priority: normal
severity: normal
status: open
title: float('nan') is True
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Jul 28 22:48:53 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 29 Jul 2021 02:48:53 +0000
Subject: [New-bugs-announce] [issue44771] Adopt changes from
 importlib_resources 5.2
Message-ID: <1627526933.52.0.0424131606686.issue44771@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Importlib_resources 5.1 and 5.2 introduced the following changes (more details at https://importlib-resources.readthedocs.io/en/latest/history.html#v5-2-1):

- Added ``simple`` module implementing adapters from a low-level resources reader interface to a ``TraversableResources`` interface.
- Legacy API (``path``, ``contents``, ...) is now supported entirely by the ``.files()`` API with a compatibility shim supplied for resource loaders without that functionality.

Let's incorporate those into the stdlib version.

----------
assignee: jaraco
components: Library (Lib)
messages: 398453
nosy: jaraco
priority: normal
severity: normal
status: open
title: Adopt changes from importlib_resources 5.2
versions: Python 3.11

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

From report at bugs.python.org  Thu Jul 29 06:28:09 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 29 Jul 2021 10:28:09 +0000
Subject: [New-bugs-announce] [issue44772] Regression in memory use of
 instances due to dictionary ordering
Message-ID: <1627554489.64.0.275505717552.issue44772@roundup.psfhosted.org>


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

class C:
    def __init__(self, cond):
        if cond:
            self.a = 1
        self.b = 2

c1 = C(True)
c2 = C(False)

   
In Python 3.5, the dictionary keys are shared
---------------------------------------------

>>> sys.getsizeof(c2)
56
>>> sys.getsizeof(c1.__dict__)
96
>>> sys.getsizeof(c2.__dict__)
96

In Python 3.9, the keys are not shared
--------------------------------------

>>> sys.getsizeof(c2)
48
>>> sys.getsizeof(c1.__dict__)
272
>>> sys.getsizeof(c2.__dict__)
232

This represents an increase of memory use for c1 of 110%. (48+272)/(56+96) == 2.1

With compact object layout (https://github.com/faster-cpython/ideas/issues/69), 
any failure to share keys will result in a tripling of memory use per object.

It is not an uncommon pattern for some attributes to initialized lazily,
which causes also prevents key-sharing.

Not only does it increase memory use, it prevents optimizations that attempt to specialize attribute access for instances of a class, as different instances will have different layouts.

The purpose of compact dicts was to save memory, but in this case we are using a lot more memory by preventing PEP 412 from working.

----------
keywords: 3.9regression
messages: 398475
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Regression in memory use of instances due to dictionary ordering

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

From report at bugs.python.org  Thu Jul 29 13:10:44 2021
From: report at bugs.python.org (Nimboss)
Date: Thu, 29 Jul 2021 17:10:44 +0000
Subject: [New-bugs-announce] [issue44773] case_insensitive kwarg to
 str.replace()
Message-ID: <1627578644.34.0.434278469351.issue44773@roundup.psfhosted.org>


New submission from Nimboss <nimit.grover24 at gmail.com>:

Currently str.replace() has 3 arguments: old, new and count.
This issue suggests the new addition of another argument called case_insensitive (type bool, defaulted to False) which determines whether to ignore case when replacing said text or not.

Currently we have to use regex or logic (see https://stackoverflow.com/questions/919056/case-insensitive-replace), but it would just be a nice QoL feature to have a case_insensitive kwarg.

----------
components: Parser
messages: 398501
nosy: lys.nikolaou, nimit.grover24, pablogsal
priority: normal
severity: normal
status: open
title: case_insensitive kwarg to str.replace()
type: enhancement

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

From report at bugs.python.org  Fri Jul 30 04:52:55 2021
From: report at bugs.python.org (Pierre Carbonnelle)
Date: Fri, 30 Jul 2021 08:52:55 +0000
Subject: [New-bugs-announce] [issue44774] incorrect sys.stdout.encoding
 within a io.StringIO buffer
Message-ID: <1627635175.38.0.412704828047.issue44774@roundup.psfhosted.org>


New submission from Pierre Carbonnelle <pierre.carbonnelle at gmail.com>:

The following code 

    print("outside:", sys.stdout.encoding)
    with redirect_stdout(io.StringIO()) as f:
        print("inside: ", sys.stdout.encoding)
    print(f.getvalue())

yields:

    outside: utf-8
    inside:  None

Because StringIO is a string buffer, the expected result is:

    outside: utf-8
    inside:  utf-8

This creates problem when using packages whose output depends on the sys.stdout.encoding, such as z3-solver.

----------
components: Library (Lib)
messages: 398528
nosy: pcarbonn
priority: normal
severity: normal
status: open
title: incorrect sys.stdout.encoding within a io.StringIO buffer
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul 30 05:28:49 2021
From: report at bugs.python.org (Yurii Karabas)
Date: Fri, 30 Jul 2021 09:28:49 +0000
Subject: [New-bugs-announce] [issue44775] Speed-up typing.cast by
 implementing it in C
Message-ID: <1627637329.45.0.691022355252.issue44775@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

In scope of https://github.com/python/cpython/pull/27262 we have introduce `_typing` module with typing related helper functions.

It will be great to speedup `typing.cast` function by implementing it in C.

I have already done it and here is results:
```
import timeit
import typing
import _typing

def _timeit(m):
    print(m.__name__, timeit.timeit("cast(int, 1)", globals={"cast": m.cast}))

_timeit(typing)
_timeit(_typing)
```

```
typing  0.0702372890082188
_typing 0.033294505992671475
```

----------
components: Library (Lib)
messages: 398529
nosy: kj, uriyyo
priority: normal
severity: normal
status: open
title: Speed-up typing.cast by implementing it in C
type: enhancement

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

From report at bugs.python.org  Fri Jul 30 05:58:11 2021
From: report at bugs.python.org (Alex)
Date: Fri, 30 Jul 2021 09:58:11 +0000
Subject: [New-bugs-announce] [issue44776] Docs on mobile do not use
 monospace font for code snippets,
 misaligning carets of improved error messages
Message-ID: <1627639091.83.0.138517548588.issue44776@roundup.psfhosted.org>


New submission from Alex <alexprengere at gmail.com>:

Now that the docs are mobile-friendly (nice!), I noticed that the code snippets are not using a monospace font (at least on my Android 10 + Chrome 92 device). This misaligns the carets of the improved errors messages, for example on the "what's new": https://docs.python.org/3.10/whatsnew/3.10.html

I attached an example on how this renders on my device.

----------
assignee: docs at python
components: Documentation
files: E7EuL0KWQAI19nx.jpg
messages: 398533
nosy: alexprengere, docs at python
priority: normal
severity: normal
status: open
title: Docs on mobile do not use monospace font for code snippets, misaligning carets of improved error messages
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50191/E7EuL0KWQAI19nx.jpg

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

From report at bugs.python.org  Fri Jul 30 09:29:28 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 30 Jul 2021 13:29:28 +0000
Subject: [New-bugs-announce] [issue44777] Create mechanism to contact
 buildbot worker owners
Message-ID: <1627651768.22.0.661777940332.issue44777@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In [this comment](https://github.com/python/cpython/pull/27436#issuecomment-889815333), I learned that it's possible to break the buildbots in a way that's not fixable with a simple code change.

The recommendation there was to contact the buildbot owners, but as far as I can tell, there's no mechanism to do that. Reading through the documentation for [buildbots](https://devguide.python.org/buildbots/) and [enrolling buildbots](https://devguide.python.org/buildworker/), there's nothing about subscribing to any list, so it seems there's no way to reach this audience.

It would be nice if there was a mailing list or other notification channel for the buildbot owners that could be used to reach out to them in an event like this.

----------
assignee: docs at python
components: Documentation
messages: 398547
nosy: docs at python, jaraco
priority: normal
severity: normal
status: open
title: Create mechanism to contact buildbot worker owners

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

From report at bugs.python.org  Fri Jul 30 09:41:30 2021
From: report at bugs.python.org (mert)
Date: Fri, 30 Jul 2021 13:41:30 +0000
Subject: [New-bugs-announce] [issue44778] os seperator error. str method of
 PureWindowsPath on Ming64 env
Message-ID: <1627652490.46.0.139202126037.issue44778@roundup.psfhosted.org>


New submission from mert <mertdemirbey1 at gmail.com>:

PureWindowsPath('C:\\Users')

When I call __str__ method of PureWindowsPath on Windows,Cygwin,Linux enviroment, I get "C:\Users" as expected. But when I run the same code on MingW environment I get "C:/Users". 

from pathlib import PureWindowsPath, Path

p = PureWindowsPath('C:\\Users')

print(str(p))

----------
messages: 398548
nosy: demirbey
priority: normal
severity: normal
status: open
title: os seperator error. str method of PureWindowsPath on Ming64 env
versions: Python 3.8

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

From report at bugs.python.org  Fri Jul 30 10:21:05 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 30 Jul 2021 14:21:05 +0000
Subject: [New-bugs-announce] [issue44779] Checkouts stale following changes
 to .gitattributes
Message-ID: <1627654865.8.0.668589058029.issue44779@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In [this comment](https://github.com/python/cpython/pull/27436#issuecomment-889815333), I learned that it's possible to get repo clones into a bad state by:

- commit a text file to main (merge a PR)
- customize the newline handling for that file in .gitattributes (in a separate PR)

Users (including buildbots) that pulled the code between these two steps will be stuck with the files at the state checked out in the first step.

Example (must be run on Windows):

PS C:\> git clone https://github.com/python/cpython --depth 100
Cloning into 'cpython'...
remote: Enumerating objects: 5946, done.
remote: Counting objects: 100% (5946/5946), done.
remote: Compressing objects: 100% (5079/5079), done.
Receiving objects: 100% (5946/5946), 24.99 MiB | 9.18 MiB/s, done.
remote: Total 5946 (delta 1382), reused 2314 (delta 758), pack-reused 0
Resolving deltas: 100% (1382/1382), done.
Updating files: 100% (4699/4699), done.
PS C:\> cd cpython
PS C:\cpython> git checkout aaa83cd^1
HEAD is now at 851cca8 Add missing gdbm dependencies to the UNIX CI (GH-27467)
PS C:\cpython> # simulate as if this rev was the the initial checkout
PS C:\cpython> git rm -r :/ > $null ; git checkout HEAD -- :/
PS C:\cpython> python -c "import pathlib; print(repr(pathlib.Path('Lib/test/test_importlib/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\r\n'
PS C:\cpython> git checkout -q aaa83cd
HEAD is now at aaa83cd bpo-44771: Apply changes from importlib_resources 5.2.1 (GH-27436)
PS C:\cpython> python -c "import pathlib; print(repr(pathlib.Path('Lib/test/test_importlib/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\r\n'
PS C:\cpython> git rm -r :/ > $null ; git checkout HEAD -- :/
PS C:\cpython> python -c "import pathlib; print(repr(pathlib.Path('Lib/test/test_importlib/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\n'

This issue doesn't exist on other repos (the file has Unix newlines in all checkouts):

PS C:\> git clone https://github.com/python/importlib_resources
Cloning into 'importlib_resources'...
remote: Enumerating objects: 2811, done.
remote: Counting objects: 100% (732/732), done.
remote: Compressing objects: 100% (400/400), done. eceiving objects:   1% (29/2811)
remote: Total 2811 (delta 456), reused 556 (delta 309), pack-reused 2079
Receiving objects: 100% (2811/2811), 446.21 KiB | 7.44 MiB/s, done.
Resolving deltas: 100% (1796/1796), done.
PS C:\> cd importlib_resources
PS C:\importlib_resources> python -c "import pathlib; print(repr(pathlib.Path('importlib_resources/tests/namespacedata01/utf-8.file').read_bytes()))" 
b'Hello, UTF-8 world!\n'


I'm not sure there's much this project can do, except maybe consider minimizing the number of files that need customization.

As a former Windows enthusiast, I found the CRLF changes to be annoying an not particularly useful, so I sought to use LF for newlines wherever possible, for simplicity and consistency. Some editors (notably Notepad) would not handle these newlines well, but almost all other editors would handle them just fine.

This project could consider standardizing on Unix newlines with a small number of exceptions rather than allowing files by default to be converted to platform-specific newlines.

I'm yet unsure what setting it is about the CPython repo that causes newlines to be customized per platform but importlib_resources does not.

----------
assignee: docs at python
components: Documentation
messages: 398552
nosy: docs at python, jaraco
priority: normal
severity: normal
status: open
title: Checkouts stale following changes to .gitattributes

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

From report at bugs.python.org  Fri Jul 30 10:52:34 2021
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 30 Jul 2021 14:52:34 +0000
Subject: [New-bugs-announce] [issue44780] Incorrect message: "Invalid
 decimal literal" (python 3.10)
Message-ID: <1627656754.25.0.173168289644.issue44780@roundup.psfhosted.org>


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

Consider the following:

>>> a = (1? 2)  # not a comma, but unicode character.

Using Python 3.9 (and earlier), we get the following correct information

>>> a = (1? 2)
  File "<stdin>", line 1
    a = (1? 2)
          ^
SyntaxError: invalid character '?' (U+201A)

Using Python 3.10, we get the following incorrect information instead:

>>> a = (1? 2)
  File "<stdin>", line 1
    a = (1? 2)
         ^
SyntaxError: invalid decimal literal

----------
messages: 398556
nosy: aroberge, pablogsal
priority: normal
severity: normal
status: open
title: Incorrect message: "Invalid decimal literal" (python 3.10)
versions: Python 3.10

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

From report at bugs.python.org  Fri Jul 30 11:49:27 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 30 Jul 2021 15:49:27 +0000
Subject: [New-bugs-announce] [issue44781] test_distutils emits deprecation
 warning about distils
Message-ID: <1627660167.89.0.985497227047.issue44781@roundup.psfhosted.org>


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

The test will be removed with distutils, so for now it should suppress the deprecation warning so that we can run the tests with warnings as errors.

----------
components: Tests
messages: 398561
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: test_distutils emits deprecation warning about distils
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul 30 12:22:34 2021
From: report at bugs.python.org (Maxime LEURENT)
Date: Fri, 30 Jul 2021 16:22:34 +0000
Subject: [New-bugs-announce] [issue44782] LRU class given as example in
 OrderedDict example not work on pop
Message-ID: <1627662154.37.0.411643198331.issue44782@roundup.psfhosted.org>


New submission from Maxime LEURENT <maxime.leurent at gmx.fr>:

Hello,

I try to use a dictionnary with limited size, and I use class LRU given in docs on OrderedDict.

Unfortunately this class is, somehow, not working on pop method.

I say somehow because if I do OrderedDict pop method by hand I don't get any Exception. I do not understand how LRU.__getitem__ is call after del, and why "value = super().__getitem__(key)" work, when "self.move_to_end(key)" don't

Code tested on python3.7 and python3.8:


from collections import OrderedDict

class LRU(OrderedDict):
    'Limit size, evicting the least recently looked-up key when full'

    def __init__(self, maxsize=128, *args, **kwds):
        self.maxsize = maxsize
        super().__init__(*args, **kwds)

    def __getitem__(self, key):
        value = super().__getitem__(key)
        self.move_to_end(key) #<=== Bug here
        return value

    def __setitem__(self, key, value):
        if key in self:
            self.move_to_end(key)
        super().__setitem__(key, value)
        if len(self) > self.maxsize:
            oldest = next(iter(self))
            del self[oldest]


d = LRU()
d["foo"] = "bar"
d.pop("foo") #<= KeyError on mode_to_send in LRU.__getitem__ method

#pop method by "hand"  
d["foo2"] = "bar"
if "foo2" in d :
    result = d["foo2"]
    del d["foo2"]
    print(result) #work fine

----------
assignee: docs at python
components: Documentation
messages: 398571
nosy: docs at python, maximeLeurent
priority: normal
severity: normal
status: open
title: LRU class given as example in OrderedDict example not work on pop
versions: Python 3.7

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

From report at bugs.python.org  Fri Jul 30 13:53:19 2021
From: report at bugs.python.org (Philip Prindeville)
Date: Fri, 30 Jul 2021 17:53:19 +0000
Subject: [New-bugs-announce] [issue44783] SSL needs client OCSP stapling
Message-ID: <1627667599.71.0.817269151693.issue44783@roundup.psfhosted.org>


New submission from Philip Prindeville <philipp at redfish-solutions.com>:

When TLS client certificates are used for authentication, servers need to ensure that the certificate is current and hasn't been revoked.  In zero-trust and other architectures with heavy use of micro-services, server-side validation of the client certs repeatedly can be a significant burden.

Forcing the client to present a signed, stapled OCSP response to the handshake eliminates this repetitive extra step.

----------
assignee: christian.heimes
components: SSL
messages: 398592
nosy: christian.heimes, pprindeville
priority: normal
severity: normal
status: open
title: SSL needs client OCSP stapling
type: enhancement

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

From report at bugs.python.org  Fri Jul 30 14:19:48 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 30 Jul 2021 18:19:48 +0000
Subject: [New-bugs-announce] [issue44784] test_importlib uses deprecated
 SelectableGroups interface
Message-ID: <1627669188.18.0.876816151356.issue44784@roundup.psfhosted.org>


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

% ./python.exe -E -We -m test -v test_importlib

....

======================================================================
ERROR: test_entry_points_groups_get (test.test_importlib.test_metadata_api.APITests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_importlib/test_metadata_api.py", line 165, in test_entry_points_groups_get
    entry_points().get('missing', 'default') == 'default'
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/importlib/metadata/__init__.py", line 400, in get
    self._warn()
    ^^^^^^^^^^^^
DeprecationWarning: SelectableGroups dict interface is deprecated. Use select.

======================================================================
ERROR: test_entry_points_groups_getitem (test.test_importlib.test_metadata_api.APITests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_importlib/test_metadata_api.py", line 155, in test_entry_points_groups_getitem
    entry_points()['entries'] == entry_points(group='entries')
    ~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/importlib/metadata/__init__.py", line 396, in __getitem__
    self._warn()
    ^^^^^^^^^^^^
DeprecationWarning: SelectableGroups dict interface is deprecated. Use select.

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

----------
components: Tests
messages: 398598
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: test_importlib uses deprecated SelectableGroups interface

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

From report at bugs.python.org  Fri Jul 30 14:24:31 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 30 Jul 2021 18:24:31 +0000
Subject: [New-bugs-announce] [issue44785] test_pickle issues
 "DeprecationWarning: The Tix Tk.."
Message-ID: <1627669471.31.0.97257359702.issue44785@roundup.psfhosted.org>


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

% ./python.exe -E -We -m test -v test_pickle

======================================================================
ERROR: test_import (test.test_pickle.CompatPickleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 367, in getmodule
    return sys.modules[module]
           ~~~~~~~~~~~^^^^^^^^
KeyError: 'tkinter.tix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 401, in test_import
    getmodule(module)
    ^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 370, in getmodule
    __import__(module)
    ^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/tkinter/tix.py", line 32, in <module>
    warnings.warn(
    ^^^^^^^^^^^^^^
DeprecationWarning: The Tix Tk extension is unmaintained, and the tkinter.tix wrapper module is deprecated in favor of tkinter.ttk

======================================================================
ERROR: test_import_mapping (test.test_pickle.CompatPickleTests) [('tkinter.tix', 'Tix')]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 367, in getmodule
    return sys.modules[module]
           ~~~~~~~~~~~^^^^^^^^
KeyError: 'tkinter.tix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 409, in test_import_mapping
    getmodule(module3)
    ^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 370, in getmodule
    __import__(module)
    ^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/tkinter/tix.py", line 32, in <module>
    warnings.warn(
    ^^^^^^^^^^^^^^
DeprecationWarning: The Tix Tk extension is unmaintained, and the tkinter.tix wrapper module is deprecated in favor of tkinter.ttk

======================================================================
ERROR: test_reverse_import_mapping (test.test_pickle.CompatPickleTests) [('Tix', 'tkinter.tix')]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 367, in getmodule
    return sys.modules[module]
           ~~~~~~~~~~~^^^^^^^^
KeyError: 'tkinter.tix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 440, in test_reverse_import_mapping
    getmodule(module3)
    ^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_pickle.py", line 370, in getmodule
    __import__(module)
    ^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/tkinter/tix.py", line 32, in <module>
    warnings.warn(
    ^^^^^^^^^^^^^^
DeprecationWarning: The Tix Tk extension is unmaintained, and the tkinter.tix wrapper module is deprecated in favor of tkinter.ttk

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

----------
components: Tests
messages: 398599
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: test_pickle issues  "DeprecationWarning: The Tix Tk.."

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

From report at bugs.python.org  Fri Jul 30 14:27:57 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 30 Jul 2021 18:27:57 +0000
Subject: [New-bugs-announce] [issue44786] test_check_c_globals "crashed" and
 then "FutureWarning: Possible nested set at position 12"
Message-ID: <1627669677.16.0.177295366811.issue44786@roundup.psfhosted.org>


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

% ./python.exe -E -We -m test -v test_check_c_globals

...

test test_check_c_globals crashed -- Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/libregrtest/runtest.py", line 335, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/libregrtest/runtest.py", line 280, in _runtest_inner2
    the_module = importlib.import_module(abstest)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1061, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1038, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1015, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 689, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 894, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_check_c_globals.py", line 6, in <module>
    from cpython.__main__ import main
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Tools/c-analyzer/cpython/__main__.py", line 18, in <module>
    from c_parser.info import KIND
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Tools/c-analyzer/c_parser/__init__.py", line 1, in <module>
    from .parser import parse as _parse
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Tools/c-analyzer/c_parser/parser/__init__.py", line 119, in <module>
    from ..info import ParsedItem
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Tools/c-analyzer/c_parser/info.py", line 10, in <module>
    import c_common.tables as _tables
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Tools/c-analyzer/c_common/tables.py", line 236, in <module>
    _COLSPEC_RE = re.compile(textwrap.dedent(r'''
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/re.py", line 229, in compile
    return _compile(pattern, flags)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/re.py", line 281, in _compile
    p = sre_compile.compile(pattern, flags)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/sre_compile.py", line 764, in compile
    p = sre_parse.parse(p, flags)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/sre_parse.py", line 948, in parse
    p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/sre_parse.py", line 443, in _parse_sub
    itemsappend(_parse(source, state, verbose, nested + 1,
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/sre_parse.py", line 834, in _parse
    p = _parse_sub(source, state, sub_verbose, nested + 1)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/sre_parse.py", line 443, in _parse_sub
    itemsappend(_parse(source, state, verbose, nested + 1,
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/sre_parse.py", line 540, in _parse
    warnings.warn(
    ^^^^^^^^^^^^^^
FutureWarning: Possible nested set at position 12

test_check_c_globals failed (uncaught exception)

----------
messages: 398600
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: test_check_c_globals "crashed" and then "FutureWarning: Possible nested set at position 12"
versions: Python 3.11

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

From report at bugs.python.org  Fri Jul 30 16:24:45 2021
From: report at bugs.python.org (Marty)
Date: Fri, 30 Jul 2021 20:24:45 +0000
Subject: [New-bugs-announce] [issue44787] Missing valid directive %D in
 datetime.strftime() documentation
Message-ID: <1627676685.12.0.81634911114.issue44787@roundup.psfhosted.org>


New submission from Marty <vpjtqwv0101 at gmail.com>:

Output of: datetime.datetime.now().strftime('%D')
is equivalent for: datetime.datetime.now().strftime('%m/%d/%y')

Is there a reason that directive %D is missing in documentation? Are there other hidden directives?
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior

----------
messages: 398606
nosy: vpjtqwv0101
priority: normal
severity: normal
status: open
title: Missing valid directive %D in datetime.strftime() documentation
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul 30 19:34:00 2021
From: report at bugs.python.org (Marty)
Date: Fri, 30 Jul 2021 23:34:00 +0000
Subject: [New-bugs-announce] [issue44788] Possibility to specify port in
 __init__ of ftplib.FTP
Message-ID: <1627688040.44.0.389798708985.issue44788@roundup.psfhosted.org>


New submission from Marty <vpjtqwv0101 at gmail.com>:

I think all that's needed is to add new parameter port in __init__ and then add it to self.connect() as argument:
    def __init__(self, host='', port=0, user='', passwd='', acct='',
                 timeout=_GLOBAL_DEFAULT_TIMEOUT, source_address=None, *,
				 encoding='utf-8'):
		self.encoding = encoding
        self.source_address = source_address
        self.timeout = timeout
        if host:
            self.connect(host, port)
            if user:
                self.login(user, passwd, acct)


Currently if I need to specify port, I have to do it like this:
with FTP() as ftp:
	ftp.connect(host, port)
	ftp.login(user, password)
	# my actions

I the port parameter would be added, I could use it like this:
with FTP(host, port, user, password) as ftp:
	# my actions

Thank you.

----------
components: Library (Lib)
messages: 398611
nosy: vpjtqwv0101
priority: normal
severity: normal
status: open
title: Possibility to specify port in __init__ of ftplib.FTP
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul 30 19:47:48 2021
From: report at bugs.python.org (Dennis Clarke)
Date: Fri, 30 Jul 2021 23:47:48 +0000
Subject: [New-bugs-announce] [issue44789] Code compliance concern in
 Parser/pegen/pegen.c
Message-ID: <1627688868.52.0.444945703099.issue44789@roundup.psfhosted.org>


New submission from Dennis Clarke <dclarke at blastwave.org>:

With release 3.9.6 I see failures in compile on three
system architectures and with three compilers. I did
check with GCC 10.2.1 ( Debian 10.2.1-6 ) on IBM Power and
also with FreeBSD UNIX LLVM/Clang 12.0.1 on AMD64 and also
with Oracle Studio C99 strict in Solaris UNIX on Fujitsu
SPARC64 wherein we see a consistent fail within the source :

    Parser/pegen/pegen.c

This is due to a standards compliance failure as per section
6.10.3 Macro replacement. Please see constraints item 4.

This fails to compile on Solaris 10 UNIX, FreeBSD 14.0 AMD64 
and on Debian Linux. 


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

----------
components: C API
messages: 398612
nosy: blastwave
priority: normal
severity: normal
status: open
title: Code compliance concern in Parser/pegen/pegen.c
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Fri Jul 30 22:20:58 2021
From: report at bugs.python.org (Michael Wang)
Date: Sat, 31 Jul 2021 02:20:58 +0000
Subject: [New-bugs-announce] [issue44790] Recursion causes Crash
Message-ID: <1627698058.13.0.682147531833.issue44790@roundup.psfhosted.org>


New submission from Michael Wang <michaeljwang10 at gmail.com>:

Ultimately it seems that deep recursion after setting the recursion limit actually crashes python

----------
components: Interpreter Core
files: bug.py
messages: 398619
nosy: michaeljwang10
priority: normal
severity: normal
status: open
title: Recursion causes Crash
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file50193/bug.py

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

From report at bugs.python.org  Sat Jul 31 06:25:14 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Jul 2021 10:25:14 +0000
Subject: [New-bugs-announce] [issue44791] Substitution of ParamSpec in
 Concatenate
Message-ID: <1627727114.02.0.621938171006.issue44791@roundup.psfhosted.org>


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

Substitution of ParamSpec in Concatenate produces weird results:

>>> import typing
>>> P = typing.ParamSpec('P')
>>> typing.Concatenate[str, P][int]
typing.Concatenate[str, int]
>>> typing.Concatenate[str, P][[int]]
typing.Concatenate[str, (<class 'int'>,)]
>>> typing.Concatenate[str, P][typing.Concatenate[int, P]]
typing.Concatenate[str, typing.Concatenate[int, ~P]]

But all these results are invalid:

>>> typing.Concatenate[str, int]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 309, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 400, in __getitem__
    return self._getitem(self, parameters)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 595, in Concatenate
    raise TypeError("The last parameter to Concatenate should be a "
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: The last parameter to Concatenate should be a ParamSpec variable.
>>> typing.Concatenate[str, (int,)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 309, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 400, in __getitem__
    return self._getitem(self, parameters)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 595, in Concatenate
    raise TypeError("The last parameter to Concatenate should be a "
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: The last parameter to Concatenate should be a ParamSpec variable.
>>> typing.Concatenate[str, [int]]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 309, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 400, in __getitem__
    return self._getitem(self, parameters)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 595, in Concatenate
    raise TypeError("The last parameter to Concatenate should be a "
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: The last parameter to Concatenate should be a ParamSpec variable.
>>> typing.Concatenate[str, typing.Concatenate[int, P]]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 309, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 400, in __getitem__
    return self._getitem(self, parameters)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 595, in Concatenate
    raise TypeError("The last parameter to Concatenate should be a "
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: The last parameter to Concatenate should be a ParamSpec variable.

I expect that

1. The last parameter to Concatenate can be a Concatenate. Inner Concatenate should merge with the external one:

Concatenate[str, Concatenate[int, P]] -> Concatenate[str, int, P]
Concatenate[str, P][Concatenate[int, P]] -> Concatenate[str, int, P]

2. The last parameter to Concatenate can be a list of types. The result should be a list of types.

Concatenate[str, [int, dict]] -> [str, int, dict]
Concatenate[str, P][[int, dict]] -> [str, int, dict]

3. The last parameter to Concatenate can be an ellipsis.

Concatenate[str, ...]
Concatenate[str, P][...] -> Concatenate[str, ...]

----------
components: Library (Lib)
messages: 398632
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Substitution of ParamSpec in Concatenate
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jul 31 07:25:20 2021
From: report at bugs.python.org (Miguel Brito)
Date: Sat, 31 Jul 2021 11:25:20 +0000
Subject: [New-bugs-announce] [issue44792] Improve syntax errors for invalid
 if expressions
Message-ID: <1627730720.99.0.100491103427.issue44792@roundup.psfhosted.org>


New submission from Miguel Brito <miguel.mdebrito at gmail.com>:

Hi, I was playing around with Python's grammar and noticed that the error message for if expression is generic, so not very informative.

I decided to improve it slightly.

*From*:

```
>>> a = 42 if True
  File "<stdin>", line 1
    a = 42 if True
                  ^
SyntaxError: invalid syntax
```

*To*:

```
$ ./python
Python 3.10.0b4 (tags/v3.10.0b4-dirty:2ba4b20854, Jul 31 2021, 11:50:15) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 42 if True
  File "<stdin>", line 1
    a = 42 if True
                  ^
SyntaxError: invalid syntax. Conditional expression expected an 'else' here.
```

----------
messages: 398633
nosy: miguendes
priority: normal
severity: normal
status: open
title: Improve syntax errors for invalid if expressions

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

From report at bugs.python.org  Sat Jul 31 08:24:26 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Jul 2021 12:24:26 +0000
Subject: [New-bugs-announce] [issue44793] Arguments ignored in substitution
 in typing.Callable
Message-ID: <1627734266.52.0.0397934894464.issue44793@roundup.psfhosted.org>


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

>>> import typing
>>> T = typing.TypeVar('T')
>>> P = typing.ParamSpec('P')
>>> C = typing.Callable[P, T]
>>> C[int, str, float]
typing.Callable[[int], str]

int substitutes P as [int], str substitutes T, and the third argument float is ignored.

----------
components: Library (Lib)
messages: 398636
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Arguments ignored in substitution in typing.Callable
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jul 31 08:40:30 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Jul 2021 12:40:30 +0000
Subject: [New-bugs-announce] [issue44794] Merge tests for typing.Callable
 and collection.abc.Callable
Message-ID: <1627735230.99.0.0983589168782.issue44794@roundup.psfhosted.org>


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

The proposed PR merges tests for typing.Callable (in test_typing.py) and collection.abc.Callable (in test_genericalias.py). All old tests are now executed for both implementations.

It has exposed a bug in typing.Callable (see issue44793) and minor bug in error message for collection.abc.Callable (missed space). It will help to support consistency of implementations in future.

----------
components: Tests
messages: 398637
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Merge tests for typing.Callable and collection.abc.Callable
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jul 31 08:44:30 2021
From: report at bugs.python.org (Andreas H.)
Date: Sat, 31 Jul 2021 12:44:30 +0000
Subject: [New-bugs-announce] [issue44795] asyncio.run does not allow for
 graceful shutdown of main task
Message-ID: <1627735470.13.0.162641750734.issue44795@roundup.psfhosted.org>


New submission from Andreas H. <ahangauer at gmx.net>:

The issue is that the main task (which was supplied to asyncio.run) has no chance to clean up its "own" sub-tasks and handle 
possible exceptions that occur during the sub-task clean up. It prevents a graceful shutdown.

There is no way to prevent the current printing of the "unhandled" exeption, even though the sub-task exception was catched by the main task. (See example below)


-- Current behavior --

When asyncio.run() receives an (unhanded) exception, all tasks are cancelled simultaneously. 
	
If any task generates an exception during its clean-up phase this is printed to the log, even though this exception is handled by the main task.
	

-- Expected behavior --
	
asyncio.run() should first cancel the main task, wait for it to complete its shutdown (and possible cancel its own sub-tasks, with exception catching), and *afterwards* cancel the remaining tasks.
	
	
-- Example Code --

For instance realize a graceful shutdown of a webserver when SIGTERM signal handler raises a SystemExit exception.




import os
import asyncio
import logging


async def main():

    logging.basicConfig(level=logging.INFO)

    async def sub_task():
        logging.info('sub_task: enter')    
        try:    
            while True:
                await asyncio.sleep(1)
                logging.info('some_task: action')
        finally:
            logging.info('sub_task: cleanup')    
            await asyncio.sleep(3)
            logging.info('sub_task: cleanup generates exception')    
            raise ValueError()
            logging.info('sub_task: cleanup end')    
    
    task = asyncio.create_task(sub_task())
                         
    try:
        while True:
            await asyncio.sleep(1)
    except Exception as e:
        logging.info(f"Main: exception {repr(e)} received: something went wrong: cancelling sub-task")
        task.cancel()
    finally:
        logging.info("Main: cleanup")
        try:
            await task
        except Exception as e:
            logging.info(f"Main: catched exception {repr(e)} from await sub_task")

try:
    asyncio.run( main() )
except KeyboardInterrupt:
    pass

-- Script Output with Ctrl+C manually generating an KeyboardInterrupt exception --


INFO:root:sub_task: enter
INFO:root:some_task: action    
        <--- CtrlC pressed here
INFO:root:Main: exception CancelledError() received: something went wrong: cancelling sub-task
INFO:root:Main: cleanup
INFO:root:sub_task: cleanup
INFO:root:sub_task: cleanup generates exception
INFO:root:Main: catched exception ValueError() from await sub_task
ERROR:asyncio:unhandled exception during asyncio.run() shutdown
task: <Task finished coro=<main.<locals>.sub_task() done, defined at D:\Benutzer\projekte\iep\apps\data_player\_signals_test\test.py:10> exception=ValueError()>
Traceback (most recent call last):
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\asyncio\runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\asyncio\base_events.py", line 574, in run_until_complete
    self.run_forever()
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\asyncio\base_events.py", line 541, in run_forever
    self._run_once()
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\asyncio\base_events.py", line 1750, in _run_once
    event_list = self._selector.select(timeout)
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\selectors.py", line 323, in select
    r, w, _ = self._select(self._readers, self._writers, [], timeout)
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\selectors.py", line 314, in _select
    r, w, x = select.select(r, w, w, timeout)
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\Benutzer\projekte\iep\apps\data_player\_signals_test\test.py", line 14, in sub_task
    await asyncio.sleep(1)
  File "C:\Users\z0013xar\AppData\Local\Continuum\anaconda3\lib\asyncio\tasks.py", line 595, in sleep
    return await future
concurrent.futures._base.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\Benutzer\projekte\iep\apps\data_player\_signals_test\test.py", line 34, in main
    await task
  File "D:\Benutzer\projekte\iep\apps\data_player\_signals_test\test.py", line 20, in sub_task
    raise ValueError()
ValueError

-- Expected Output --

Same as above but without

  "ERROR:asyncio:unhandled exception during asyncio.run() shutdown"

and following traceback

----------
components: asyncio
messages: 398638
nosy: andreash, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.run does not allow for graceful shutdown of main task
type: behavior

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

From report at bugs.python.org  Sat Jul 31 09:31:29 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Jul 2021 13:31:29 +0000
Subject: [New-bugs-announce] [issue44796] Add __parameters__ and __getitem__
 in TypeVar and ParamSpec
Message-ID: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>


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

Adding __parameters__ and __getitem__ in TypeVar and ParamSpec allows to generalize and simplify the code (especially the C code) and allows to add more runtime checks. It may open ways for further simplification.

Unfortunately it is not compatible with issue44098, so the latter changes should be reverted.

----------
components: Library (Lib)
messages: 398640
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add __parameters__ and __getitem__ in TypeVar and ParamSpec
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Jul 31 12:19:59 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 31 Jul 2021 16:19:59 +0000
Subject: [New-bugs-announce] [issue44797] test_socket should expect warnings
 in truncated-data tests
Message-ID: <1627748399.43.0.897184289547.issue44797@roundup.psfhosted.org>


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

I believe these warnings are a feature so the tests should expect them. Patch included.


% ./python.exe -E -We -m test -v test_socket

======================================================================
ERROR: testSecondCmsgTruncInData (test.test_socket.RecvmsgRFC3542AncillaryUDP6Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 4176, in testSecondCmsgTruncInData
    msg, ancdata, flags, addr = self.doRecvmsg(
                                ^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2701, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testSingleCmsgTruncInData (test.test_socket.RecvmsgRFC3542AncillaryUDP6Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 4072, in testSingleCmsgTruncInData
    msg, ancdata, flags, addr = self.doRecvmsg(
                                ^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2701, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testSecondCmsgTruncInData (test.test_socket.RecvmsgIntoRFC3542AncillaryUDP6Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 4176, in testSecondCmsgTruncInData
    msg, ancdata, flags, addr = self.doRecvmsg(
                                ^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2792, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testSingleCmsgTruncInData (test.test_socket.RecvmsgIntoRFC3542AncillaryUDP6Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 4072, in testSingleCmsgTruncInData
    msg, ancdata, flags, addr = self.doRecvmsg(
                                ^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2792, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen0 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3749, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2701, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen0Plus1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3755, in testCmsgTruncLen0Plus1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2701, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3761, in testCmsgTruncLen1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(SIZEOF_INT),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2701, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen2Minus1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3768, in testCmsgTruncLen2Minus1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(2 * SIZEOF_INT) - 1,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2701, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen0 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3749, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2792, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen0Plus1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3755, in testCmsgTruncLen0Plus1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2792, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3761, in testCmsgTruncLen1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(SIZEOF_INT),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2792, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

======================================================================
ERROR: testCmsgTruncLen2Minus1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3768, in testCmsgTruncLen2Minus1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(2 * SIZEOF_INT) - 1,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 3729, in checkTruncatedArray
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_socket.py", line 2792, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeWarning: received malformed or improperly-truncated ancillary data

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

----------
components: Tests
messages: 398644
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: test_socket should expect warnings in truncated-data tests
type: behavior

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

From report at bugs.python.org  Sat Jul 31 12:32:45 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 31 Jul 2021 16:32:45 +0000
Subject: [New-bugs-announce] [issue44798] test_enum emits a deprecation
 warning from test_custom_strenum_with_warning
Message-ID: <1627749165.55.0.6553669311.issue44798@roundup.psfhosted.org>


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

% ./python.exe -E -We -m test -v test_enum


======================================================================
ERROR: test_custom_strenum_with_warning (test.test_enum.TestEnum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_enum.py", line 2324, in test_custom_strenum_with_warning
    self.assertEqual(OkayEnum.one, '{}'.format(OkayEnum.one))
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/enum.py", line 1006, in __format__
    warnings.warn(
    ^^^^^^^^^^^^^^
DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an integer-based Enum, to maintain the current display

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

----------
components: Tests
messages: 398647
nosy: ethan.furman, iritkatriel
priority: normal
severity: normal
status: open
title: test_enum emits a deprecation warning from test_custom_strenum_with_warning

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

From report at bugs.python.org  Sat Jul 31 13:19:44 2021
From: report at bugs.python.org (Komiya Takeshi)
Date: Sat, 31 Jul 2021 17:19:44 +0000
Subject: [New-bugs-announce] [issue44799] typing.get_type_hints() raises
 TypeError for a variable annotated by dataclasses.InitVar
Message-ID: <1627751984.55.0.589090528607.issue44799@roundup.psfhosted.org>


New submission from Komiya Takeshi <i.tkomiya at gmail.com>:

I found `typing.get_type_hints()` raises TypeError for a variable annotated by `dataclasses.InitVar` when lazy annotations evaluation-feature is enabled (a.k.a `__future__.annotations`).

```
$ cat test.py
from __future__ import annotations
from dataclasses import dataclass, InitVar
from typing import get_type_hints

@dataclass
class Foo:
    attr: InitVar[int]


get_type_hints(Foo)
```

```
$ python -V
Python 3.9.6
$ python test.py
Traceback (most recent call last):
  File "/Users/tkomiya/work/sphinx/test.py", line 10, in <module>
    get_type_hints(Foo)
  File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 1424, in get_type_hints
    value = _eval_type(value, base_globals, localns)
  File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 290, in _eval_type
    return t._evaluate(globalns, localns, recursive_guard)
  File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 545, in _evaluate
    type_ =_type_check(
  File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 164, in _type_check
    raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Forward references must evaluate to types. Got dataclasses.InitVar[int].
```

It goes well if lazy annotations evaluation is disabled.

----------
components: Library (Lib)
messages: 398650
nosy: tkomiya
priority: normal
severity: normal
status: open
title: typing.get_type_hints() raises TypeError for a variable annotated by dataclasses.InitVar
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jul 31 21:48:31 2021
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Aug 2021 01:48:31 +0000
Subject: [New-bugs-announce] [issue44800] Code readability: rename
 interpreter frames to execution frames
Message-ID: <1627782511.03.0.274598412143.issue44800@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

When merging the bpo-44590 changes into my PEP 558 implementation branch, I found it very hard to follow when the code was referring to the new interpreter frames rather than the existing Python frame objects that were historically used for both execution and introspection.

The "interpreter frame" name was also a little confusing, since the introspection frames are still associated with a specific interpreter, they're just not required for code execution anymore, only for code introspection APIs that call for a full Python object.

So, inspired by the "gi_xframe" (etc) attributes added in https://github.com/python/cpython/pull/27077, I'm proposing the following internal refactoring:

* Rename "pycore_frame.h" to "pycore_xframe.h"
* Rename the _interpreter_frame struct to _execution_frame
* Rename the type from InterpreterFrame to ExecFrame
* Use "xf_" rather than "f_" as the struct field prefix on execution frames
* Use "xframe" and "xf" rather than "frame" and "f" for execution frame variables
* Consistently use _PyExecFrame as the access function prefix, rather than a confusing mixture of _PyFrame and _PyInterpreterFrame
* Rename _PyThreadState_PushFrame to _PyThreadState_PushExecFrame
* Rename _PyThreadState_PopFrame to _PyThreadState_PopExecFrame

----------
messages: 398675
nosy: Mark.Shannon, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Code readability: rename interpreter frames to execution frames
type: enhancement
versions: Python 3.11

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