From report at bugs.python.org  Thu Apr  1 02:47:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Apr 2021 06:47:31 +0000
Subject: [New-bugs-announce] [issue43688] [C API] Fix Py_INCREF and
 Py_DECREF in the limited C API for Python built in debug mode
Message-ID: <1617259651.04.0.276896882913.issue43688@roundup.psfhosted.org>


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

Currently, setup.py doesn't build xxlimited and xxlimited_35 extension modules with the limited C API if Python is built in debug mode. I only found two functions affected by Py_DEBUG macro in the limited C API: Py_INCREF() and Py_DECREF().

Example:
---
#if defined(Py_DEBUG) && !defined(Py_REF_DEBUG)
#define Py_REF_DEBUG
#endif

static inline void _Py_INCREF(PyObject *op)
{
#ifdef Py_REF_DEBUG
    _Py_RefTotal++;
#endif
    op->ob_refcnt++;
}
#define Py_INCREF(op) _Py_INCREF(_PyObject_CAST(op))
---

If Py_DEBUG is defined (Python built in debug mode), Py_INCREF() increments the private _Py_RefTotal variable.

The limited C API is supposed to provide a stable ABI, but Py_INCREF() leaks _Py_RefTotal implementation if Python is built in debug mode.

I propose to modify Py_INCREF() and Py_DECREF() of the limited C API to always declare them as opaque function calls. The regular (non limited) C API will continue to use the same static inline functions.

See also https://github.com/python/cpython/pull/25115 and bpo-41111 "[C API] Convert a few stdlib extensions to the limited C API (PEP 384)".

Note: Py_XINCREF() and Py_XDECREF() should be fine.

----------
components: C API
messages: 389956
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Fix Py_INCREF and Py_DECREF in the limited C API for Python built in debug mode
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  1 04:09:11 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Thu, 01 Apr 2021 08:09:11 +0000
Subject: [New-bugs-announce] [issue43689] difflib: mention other
 "problematic" characters in documentation
Message-ID: <1617264551.39.0.962049035907.issue43689@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

In the documentation you can currently read for the "?"-output:

"These lines can be confusing if the sequences contain tab characters."

>From first hand experience :-), I can assure it is also very confusing for other types of whitespace characters, such as spaces and line breaks.

I'd like to add the other characters to the documentation.

----------
assignee: docs at python
components: Documentation
messages: 389961
nosy: docs at python, jugmac00
priority: normal
pull_requests: 23879
severity: normal
status: open
title: difflib: mention other "problematic" characters in documentation
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr  1 05:37:33 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Apr 2021 09:37:33 +0000
Subject: [New-bugs-announce] [issue43690] [C API] stable_abi.py script must
 not include PyType_HasFeature() static inline function in the stable ABI
Message-ID: <1617269853.61.0.950135288092.issue43690@roundup.psfhosted.org>


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

I just ran "make regen-limited-abi" and it added PyType_HasFeature():

commit baf10da75072d1f8ec714d3c2c8550d34db343a9
Author: Victor Stinner <vstinner at python.org>
Date:   Thu Apr 1 11:29:46 2021 +0200

    bpo-43688: Run make regen-limited-abi (GH-25134)

diff --git a/Doc/data/stable_abi.dat b/Doc/data/stable_abi.dat
index 3adee103bc..ed20521b7f 100644
--- a/Doc/data/stable_abi.dat
+++ b/Doc/data/stable_abi.dat
@@ -192,6 +192,7 @@ PyExc_ConnectionRefusedError
 PyExc_ConnectionResetError
 PyExc_DeprecationWarning
 PyExc_EOFError
+PyExc_EncodingWarning
 PyExc_EnvironmentError
 PyExc_Exception
 PyExc_FileExistsError
@@ -615,6 +616,7 @@ PyType_GetFlags
 PyType_GetModule
 PyType_GetModuleState
 PyType_GetSlot
+PyType_HasFeature
 PyType_IsSubtype
 PyType_Modified
 PyType_Ready


The problem is that PyType_HasFeature() is currently implemented as a static inline function in the limited C API for best performance.

Issue about PyType_HasFeature() performance in CPython itself:
https://bugs.python.org/issue39542#msg372962

Currently, PyType_HasFeature() is declared in Include/object.h as:

static inline int
PyType_HasFeature(PyTypeObject *type, unsigned long feature)
{
    unsigned long flags;
#ifdef Py_LIMITED_API
    // PyTypeObject is opaque in the limited C API
    flags = PyType_GetFlags(type);
#else
    flags = type->tp_flags;
#endif
    return ((flags & feature) != 0);
}

IMO static inline functions must not be listed in the stable *ABI*. At the ABI level, libpython doesn't export "PyType_HasFeature" symbol:

$ objdump -T /lib64/libpython3.10.so.1.0|grep '\<PyObject_CallFunction\>'
00000000000fedf0 g    DF .text	00000000000000d0  Base        PyObject_CallFunction
$ objdump -T /lib64/libpython3.10.so.1.0|grep '\<PyType_HasFeature\>'
# nothing

"PyObject_CallFunction" symbol is exported, but not "PyType_HasFeature".

--

Maybe for the stable ABI, it would be a good idea to export PyType_HasFeature() as an opaque function. But that's out of the scope of this issue which is about the stable_abi.py script ;-)

----------
components: C API
messages: 389964
nosy: pablogsal, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: [C API] stable_abi.py script must not include PyType_HasFeature() static inline function in the stable ABI
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  1 05:42:56 2021
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 01 Apr 2021 09:42:56 +0000
Subject: [New-bugs-announce] [issue43691] Comparison of OrderedDict() and
 dict()
Message-ID: <1617270176.28.0.957679341953.issue43691@roundup.psfhosted.org>


New submission from ???? ????????? <socketpair at gmail.com>:

OrderedDict([(1,2), (3,4)]) == OrderedDict([(3,4), (1,2)])
Out[1]: False    # OK

dict([(1,2), (3,4)]) == dict([(3,4), (1,2)])
Out[2]: True     # OK

dict([(1,2), (3,4)]) == OrderedDict([(3,4), (1,2)])
Out[3]: True     # NOT OK, since actual order is different

OrderedDict([(1,2), (3,4)]) == dict([(3,4), (1,2)])
Out[4]: True     # NOT OK, since actual orderd is different


I propose two options to fix it:

1. Return True when comparing anything with OrderedDict iff order is the same.
2. Raise TypeError when someone tries to compare OrderedDict() and dict(). # I think it's better.

----------
components: Library (Lib)
messages: 389965
nosy: socketpair
priority: normal
severity: normal
status: open
title: Comparison of OrderedDict() and dict()
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Apr  1 06:28:05 2021
From: report at bugs.python.org (Carsten Docktor)
Date: Thu, 01 Apr 2021 10:28:05 +0000
Subject: [New-bugs-announce] [issue43692] Raise SyntaxError on implicit
 string concatentation in list
Message-ID: <1617272885.12.0.631985643929.issue43692@roundup.psfhosted.org>


New submission from Carsten Docktor <carsten.docktor at gmail.com>:

I recently found several bugs, which came from the "feature" shown below.
Is python supposed to use string concatenation in a list environment like this? Why would this be appreciated?

## Expected Behavior

The example below should raise a SyntaxErorr for a missing comma.
String concatenation in a list should require brackets.

## Current Behavior

Missing commas in a string list lead to unnoticed concatenated strings.


## Steps to Reproduce

```python
my_list = [
  "a",
  "b"
  "c",
  "d"
]
interpreted_list = [
  "a",
  "bc",
  "d",
]
assert my_list == interpreted_list  # unwanted behavior
```

----------
components: Interpreter Core
messages: 389970
nosy: carsten.docktor
priority: normal
severity: normal
status: open
title: Raise SyntaxError on implicit string concatentation in list
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  1 07:33:50 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 01 Apr 2021 11:33:50 +0000
Subject: [New-bugs-announce] [issue43693] Logically merge cell and locals
 array. They are already contiguous in memory
Message-ID: <1617276830.47.0.331349599371.issue43693@roundup.psfhosted.org>


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

In the interpreter and compiler, the "fast" locals array and cells array are treated separately. By merging them in the compiler, the interpreter can be simplified a bit.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 389974
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Logically merge cell and locals array. They are already contiguous in memory
type: performance

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

From report at bugs.python.org  Thu Apr  1 07:33:52 2021
From: report at bugs.python.org (A_D)
Date: Thu, 01 Apr 2021 11:33:52 +0000
Subject: [New-bugs-announce] [issue43694] Tkinter scaling does not work on
 some linux systems
Message-ID: <1617276832.36.0.11586467537.issue43694@roundup.psfhosted.org>


New submission from A_D <aunderscored at gmail.com>:

When using scaling (as in root.tk.call('scaling', somenum)), some linux systems appear to simply disregard the change. 

I recently reinstalled from Ubuntu to OpenSUSE Tumbleweed and found that scaling straight up did not work in the application I tried or the test application -- https://github.com/Athanasius/tk-scaling. (image attached)

Tested on python 3.8.8 and 3.9.2 (pyenv)

----------
components: Tkinter
files: Screenshot_20210401_132045.png
messages: 389975
nosy: aunderscored
priority: normal
severity: normal
status: open
title: Tkinter scaling does not work on some linux systems
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49924/Screenshot_20210401_132045.png

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

From report at bugs.python.org  Thu Apr  1 08:25:56 2021
From: report at bugs.python.org (wyz23x2)
Date: Thu, 01 Apr 2021 12:25:56 +0000
Subject: [New-bugs-announce] [issue43695] Improve `=` in f-strings
Message-ID: <1617279956.14.0.806481637406.issue43695@roundup.psfhosted.org>


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

In Python 3.8, `=` was added into f-strings:
>>> a, b, c = 20, 40, 10
>>> f'{a+b-c=}'
a+b-c=50
But if `20+40-10` is wanted, this needs to be written:
>>> f'{a}+{b}-{c}={a+b-c}'
20+40-10=50
So something could be added. For example, `?` (this doesn't mean I recommend the question mark):
>>> f'{a?+b?-c?=}'
20+40-10=50
>>> f'{a+b?-c=}'
a+40-c=50
>>> f'{a+b-c=?}'  # Suffix `=` to apply to all?
20+40-10

Suggestions?

----------
components: Interpreter Core
messages: 389979
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Improve `=` in f-strings
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  1 09:04:02 2021
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQmtC+0L/RgtC10LI=?=)
Date: Thu, 01 Apr 2021 13:04:02 +0000
Subject: [New-bugs-announce] [issue43696] High cpu usage using asyncio
 streams
Message-ID: <1617282242.21.0.755675645798.issue43696@roundup.psfhosted.org>


New submission from ????? ?????? <romikforest at gmail.com>:

Hi. I have a high cpu usage using asyncio streams/sockets with connection pool (I tried on cpython 3.8-3.9 on mac and debian). Seems some noop handler is continously called polling ports in selectors.
Here is a simple example to reproduce https://github.com/romikforest/asyncio_streams_high_cpu_usage2

Thank you a lot if you can take a look.

----------
components: asyncio
messages: 389981
nosy: asvetlov, romikforest, yselivanov
priority: normal
severity: normal
status: open
title: High cpu usage using asyncio streams
type: performance
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr  1 11:49:52 2021
From: report at bugs.python.org (Paul Moore)
Date: Thu, 01 Apr 2021 15:49:52 +0000
Subject: [New-bugs-announce] [issue43697] Importlib documentation does not
 cover how meta path finders should handle namespace packages
Message-ID: <1617292192.88.0.998553072276.issue43697@roundup.psfhosted.org>


New submission from Paul Moore <p.f.moore at gmail.com>:

I am trying to write a meta path finder that "redirects" module loads to a different part of the filesystem. There's not much information in the importlib documentation, but PEP 451 says "find_spec() must return a spec with "loader" set to None (a.k.a. not set) and with submodule_search_locations set to the same portions as would have been provided by find_loader()".

I have done that, and it does work as long as all parts of the namespace package are handled by the *same* metapath loader. But if I have (for instance) one portion of the namespace package handled by my finder, and want to leave the filesystem finder to handle other parts, that doesn't work.

Is there a supported way to set up a finder on sys.meta_path which will expose just one "portion" of a namespace package?

----------
assignee: brett.cannon
components: Documentation
messages: 389997
nosy: brett.cannon, paul.moore
priority: normal
severity: normal
status: open
title: Importlib documentation does not cover how meta path finders should handle namespace packages
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  1 14:18:39 2021
From: report at bugs.python.org (Vladimir Ryabtsev)
Date: Thu, 01 Apr 2021 18:18:39 +0000
Subject: [New-bugs-announce] [issue43698] Use syntactically correct examples
 on abc package page
Message-ID: <1617301119.32.0.268651511376.issue43698@roundup.psfhosted.org>


New submission from Vladimir Ryabtsev <greatvovan at gmail.com>:

There are code snippets on the package's page (https://docs.python.org/3.10/library/abc.html) like this:

class C(ABC):
    @classmethod
    @abstractmethod
    def my_abstract_classmethod(cls, ...):
        ...

Here, the author probably wanted to demonstrate that the method may have _any other arguments_ in addition to `cls`, but it makes the code not compilable:

    def my_abstract_classmethod(cls, ...):
                                     ^
SyntaxError: invalid syntax

Additionally it uses the same Ellipsis as in the method's body (that is supposed to indicate a stub), which is confusing.

I think that all code samples must be syntactically correct, so that if a reader copypastes them into their code editor they would work right away. I suggest to remove ellipsis in the argument lists everywhere on the page and replace them with one of the following:

- sample parameters such as `a, b, c` or `my_arg1, my_arg2`,
- `*args, **kwargs`,
- nothing.

----------
assignee: docs at python
components: Documentation
messages: 390004
nosy: Vladimir Ryabtsev, docs at python
priority: normal
severity: normal
status: open
title: Use syntactically correct examples on abc package page
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr  1 16:05:39 2021
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Lu=C3=ADs_Lopes_da_Silva?=)
Date: Thu, 01 Apr 2021 20:05:39 +0000
Subject: [New-bugs-announce] [issue43699] ERROR: Could not find a version
 that satisfies the requirement MetaTrader5
Message-ID: <1617307539.35.0.971168865861.issue43699@roundup.psfhosted.org>


New submission from Andr? Lu?s Lopes da Silva <clonageinvitro at yahoo.com.br>:

Dear,

I am trying to install MetaTrader5 via pip. But this return this message:

Defaulting to user installation because normal site-packages is not writeable
WARNING: Keyring is skipped due to an exception: Failed to unlock the keyring!
ERROR: Could not find a version that satisfies the requirement MetaTrader5
ERROR: No matching distribution found for MetaTrader5

I use linux ubuntu.

Thanks

----------
components: Installation
messages: 390010
nosy: andre_luis
priority: normal
severity: normal
status: open
title: ERROR: Could not find a version that satisfies the requirement MetaTrader5
versions: Python 3.6

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

From report at bugs.python.org  Thu Apr  1 18:52:53 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 01 Apr 2021 22:52:53 +0000
Subject: [New-bugs-announce] [issue43700] Replace Zulip badge with Discourse
 badge in README
Message-ID: <1617317573.33.0.295703072915.issue43700@roundup.psfhosted.org>


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

Suggesting to follow the dev guide and replace the Zulip badge with a Discourse badge in README.rst.

Quoting the dev guide, section 2.4. Zulip:
"This is no longer actively monitored by core devs. Consider asking your questions on Discourse or on the python-dev mailing list."


See also:
- https://python.zulipchat.com
- https://devguide.python.org/help/#zulip
- https://discuss.python.org/t/discourse-github-integration/355
- https://github.com/python/devguide/issues/625
- https://github.com/python/devguide/pull/630

----------
assignee: docs at python
components: Documentation
messages: 390016
nosy: Mariatta, docs at python, erlendaasland, willingc
priority: normal
severity: normal
status: open
title: Replace Zulip badge with Discourse badge in README

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

From report at bugs.python.org  Thu Apr  1 23:36:06 2021
From: report at bugs.python.org (Masoud Azizi)
Date: Fri, 02 Apr 2021 03:36:06 +0000
Subject: [New-bugs-announce] [issue43701] Add this optionality
Message-ID: <1617334566.18.0.191998092151.issue43701@roundup.psfhosted.org>


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

I want to rediuse two var togeder!
When i do that buy sum is rediuse to zero and not effect the sellsum
buySum[pair] -= sellSum[pair]
sellSum[pair] -= buySum[pair]

Cuz of that i try this statment but its not work!
Its a simple code that will python support it:

buySum[pair],sellSum[pair] -= sellSum[pair], buySum[pair]

Please add this optionallity to python

----------
messages: 390032
nosy: mablue
priority: normal
severity: normal
status: open
title: Add this optionality
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  2 00:16:14 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 02 Apr 2021 04:16:14 +0000
Subject: [New-bugs-announce] [issue43702] [Windows] correctly sort and
 remove duplicates in _winapi getenvironment()
Message-ID: <1617336974.49.0.41114511179.issue43702@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

getenvironment() in Modules/_winapi.c needs to sort variables in the environment block and remove duplicates case insensitively [1]. 

The sort order used to matter with SetEnvironmentVairableW(). As soon as it reached a name in the environment block that compared greater than the target name, it would insert a new variable. Nowadays, SetEnvironmentVairableW() searches the entire environment block before inserting a new value. Regardless, at the very least, getenvironment() is not well-behaved and not setting the environment in the documented sort order that users, and possibly other programs, expect.

Case-insensitive sorting in Windows uses upper case. The variable names in the mapping can be added to a list and sorted with a key function that's based on LCMapStringEx() [2], with the flag LCMAP_UPPERCASE. Loop over the sorted list to create the environment block. Remove duplicates by skipping a name that compares equal to the previously stored name according to CompareStringOrdinal() [3].

_winapi.LCMapStringEx(src, flags=LCMAP_UPPERCASE, locale=LOCALE_NAME_INVARIANT) could also be used in ntpath.normcase(), which would resolve bpo-42658.

---

[1] https://docs.microsoft.com/en-us/windows/win32/procthread/changing-environment-variables
[2] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-lcmapstringex
[3] https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-comparestringordinal

----------
components: Extension Modules, Windows
messages: 390038
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: [Windows] correctly sort and remove duplicates in _winapi getenvironment()
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  2 07:03:35 2021
From: report at bugs.python.org (Romuald Brunet)
Date: Fri, 02 Apr 2021 11:03:35 +0000
Subject: [New-bugs-announce] [issue43703] xml.etree parser does not accept
 valid control characters
Message-ID: <1617361415.63.0.134050826709.issue43703@roundup.psfhosted.org>


New submission from Romuald Brunet <romuald.brunet at gmail.com>:

Python XML parser (xml.etree) does not seems to allow control characters that are invalid in XML 1.0, but valid in XML 1.1 [1] [2]


Considering the following sample:


import xml.etree.ElementTree as ET

bad = '<?xml version="1.1"?><foo>bar &#x19; baz</foo>'
print(ET.fromstring(bad))


The parser raises the following error:
ParseError: reference to invalid character number: line 1, column 30



[1] https://www.w3.org/TR/xml11/Overview.html#charsets
[2] https://www.w3.org/TR/xml11/Overview.html#sec-xml11

----------
components: XML
messages: 390050
nosy: Romuald
priority: normal
severity: normal
status: open
title: xml.etree parser does not accept valid control characters
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr  2 12:28:21 2021
From: report at bugs.python.org (Steve Newcomb)
Date: Fri, 02 Apr 2021 16:28:21 +0000
Subject: [New-bugs-announce] [issue43704] ShareableList() raises TypeError
 when passing "name" keyword
Message-ID: <1617380901.37.0.319201562014.issue43704@roundup.psfhosted.org>


New submission from Steve Newcomb <srn at coolheads.com>:

This is especially weird because the Python source code says:

class ShareableList:
[...]
   def __init__(self, sequence=None, *, name=None):

----------
components: Library (Lib)
files: shareableListBug.txt
messages: 390080
nosy: steve.newcomb
priority: normal
severity: normal
status: open
title: ShareableList() raises TypeError when passing "name" keyword
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49928/shareableListBug.txt

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

From report at bugs.python.org  Fri Apr  2 12:32:20 2021
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 02 Apr 2021 16:32:20 +0000
Subject: [New-bugs-announce] [issue43705] [docs] Document that SyntaxError's
 offsets are 1-indexed
Message-ID: <1617381140.86.0.138560656668.issue43705@roundup.psfhosted.org>


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

As pointed out by Guido in https://bugs.python.org/issue43555, we switched to making the column offsets for SyntaxError be 1-indexed consistently in https://bugs.python.org/issue34683

The rationale is explained by Guido and expanded upon in follow up comments here: https://github.com/python/cpython/pull/9338#pullrequestreview-155989089 

This property however was not actually ever added to SyntaxError's documentation: https://docs.python.org/3/library/exceptions.html#SyntaxError

----------
assignee: docs at python
components: Documentation
messages: 390081
nosy: ammar2, docs at python, gvanrossum, terry.reedy
priority: normal
severity: normal
status: open
title: [docs] Document that SyntaxError's offsets are 1-indexed
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr  2 13:36:13 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 02 Apr 2021 17:36:13 +0000
Subject: [New-bugs-announce] [issue43706] enumerate() instantiation time
 reducing by using PEP 590 vectorcall
Message-ID: <1617384973.81.0.220949587115.issue43706@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

Finally, I success to implement PEP 590 for enumerate type which is the well-used type in Python.

Amazingly enhanced!

+-----------------+------------------------+----------------------------+
| Benchmark       | enumerate_bench_master | enumerate_bench_vectorcall |
+=================+========================+============================+
| bench enumerate | 527 ns                 | 380 ns: 1.39x faster       |
+-----------------+------------------------+----------------------------+

----------
files: bench_enumerate.py
messages: 390083
nosy: corona10, vstinner, xtreak
priority: normal
severity: normal
status: open
title: enumerate() instantiation time reducing by using PEP 590 vectorcall
Added file: https://bugs.python.org/file49929/bench_enumerate.py

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

From report at bugs.python.org  Fri Apr  2 13:57:47 2021
From: report at bugs.python.org (Maximilian Roos)
Date: Fri, 02 Apr 2021 17:57:47 +0000
Subject: [New-bugs-announce] [issue43707] onerror in tempfile has an invalid
 raise expression
Message-ID: <1617386267.48.0.621517587734.issue43707@roundup.psfhosted.org>


New submission from Maximilian Roos <m at maxroos.com>:

The raise expression [here](https://github.com/python/cpython/blob/ad442a674ca443feec43a88a2d3671784712e550/Lib/tempfile.py#L826) isn't valid, since it isn't in an except block.

It'll still raise, given it's invalid, though not with the exception it should be raising with...

I think this diff will fix it, I can put this in as a PR if that's reasonable. Though I'm not sure how to test it ? we need to generate an error that's not covered by the existing cases. 

```diff

diff --git a/Lib/tempfile.py b/Lib/tempfile.py
index efcf7a7fb3..227e25d0fc 100644
--- a/Lib/tempfile.py
+++ b/Lib/tempfile.py
@@ -823,7 +823,7 @@ def resetperms(path):
                 pass
             else:
                 if not ignore_errors:
-                    raise
+                    raise exc_info[1]
 
         _shutil.rmtree(name, onerror=onerror)

```

----------
components: Library (Lib)
messages: 390084
nosy: max-sixty
priority: normal
severity: normal
status: open
title: onerror in tempfile has an invalid raise expression
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr  2 16:30:08 2021
From: report at bugs.python.org (WHK)
Date: Fri, 02 Apr 2021 20:30:08 +0000
Subject: [New-bugs-announce] [issue43708] Tkinter theme settings object
 schema is missing
Message-ID: <1617395408.51.0.908032380158.issue43708@roundup.psfhosted.org>


New submission from WHK <whk at elhacker.net>:

By example

style = ttk.Style()
style.theme_settings('default', settings={
    '.': []
})

Tkinter settings schema or typed data is missing. By example:

_tkinter.TclError: Invalid state name d

This error message does not provide the missing parameter information, by example expected: "Tupe is required in .::Map background, not dict"

----------
components: Tkinter
messages: 390097
nosy: WHK102
priority: normal
severity: normal
status: open
title: Tkinter theme settings object schema is missing
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr  2 16:56:43 2021
From: report at bugs.python.org (David Bolen)
Date: Fri, 02 Apr 2021 20:56:43 +0000
Subject: [New-bugs-announce] [issue43709] Windows Tools\buildbot\clean.bat
 misses some needed pyc/pyo removal
Message-ID: <1617397003.07.0.230481208149.issue43709@roundup.psfhosted.org>


New submission from David Bolen <db3l.net at gmail.com>:

The Tools\buildbot\clean.bat script used on Windows only removes pyc/pyo files from the Lib tree, leaving some files beneath Tools (clinic and peg_generator) and Parser (asdl).  This can cause failures following commits that affect those files, such as fcb55c0037baab6f98f91ee38ce84b6f874f034a (in issue #27129) leading to subsequent crashes or anomalous behavior.

This appears to have been true for a while, though only the 3.10 branch ran into the issue, so any fix might also be back-ported to the other active branches.

----------
components: Build, Windows
messages: 390098
nosy: db3l, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr  2 23:09:40 2021
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 03 Apr 2021 03:09:40 +0000
Subject: [New-bugs-announce] [issue43710] Access violations in C extension
 modules on Python 3.9.3
Message-ID: <1617419380.7.0.273976800885.issue43710@roundup.psfhosted.org>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

First reported at https://github.com/numpy/numpy/issues/18720

After upgrading to Python 3.9.3, 32-bit on Windows, importing numpy (installed via `pip install numpy`) crashes:

```
Microsoft Windows [Version 10.0.19041.906]
C:\Python39-32>python -X dev
Python 3.9.3 (tags/v3.9.3:e723086, Apr  2 2021, 11:01:03) [MSC v.1928 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Windows fatal exception: access violation

Current thread 0x0000105c (most recent call first):
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 1116 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 1116 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 1116 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "C:\Python39-32\lib\site-packages\numpy\random\_pickle.py", line 1 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1058 in _handle_fromlist
  File "C:\Python39-32\lib\site-packages\numpy\random\__init__.py", line 179 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1058 in _handle_fromlist
  File "C:\Python39-32\lib\site-packages\numpy\__init__.py", line 156 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<stdin>", line 1 in <module>
```

Rebuilding numpy from source against Python 3.9.3 fixes this crash, but many other packages compiled against older versions of Python 3.9.x still crash.

I think this might be due to <https://github.com/python/cpython/commit/8b795ab5541d8a4e69be4137dfdc207714270b77#diff-7285576bdacf86fe37274d3d0d399c29b4be2959005f60ac0729615d8fca9186>.

In `bpo-42500: Fix recursion in or after except (GH-23568) (#24501)`, the public `PyThreadState` struct changed. This breaks ABI compatibility for code that is directly accessing the `PyThreadState` struct members, which is not uncommon. E.g. in Cython <https://github.com/cython/cython/blob/0.29.x/Cython/Utility/Exceptions.c#L93-L115>. This code will fail on 32-bit. On 64-bit it passes because of fortunate struct alignment AFAICT.

----------
components: Extension Modules, Windows
messages: 390116
nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Access violations in C extension modules on Python 3.9.3
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  3 07:14:45 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 03 Apr 2021 11:14:45 +0000
Subject: [New-bugs-announce] [issue43711] cgi.log() uses default encoding
Message-ID: <1617448485.13.0.0997125789573.issue43711@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

See cgi.initlog():
https://github.com/python/cpython/blob/b2a91e0c9ee18b50cc86b21211c2258520a9f5d0/Lib/cgi.py#L82

```
            logfp = open(logfile, "a")
```

This feature is not documented but can be used like this.

```
import cgi
cgi.logfile="myapp.log"
cgi.log("?????")
```

I want to change log file encoding to UTF-8. Although this is backward incompatible change, it unlikely break user application because it just change the logfile encoding.

UTF-8 is safer than locale encoding because UTF-8 supports all valid Unicode strings.

----------
components: Library (Lib)
messages: 390120
nosy: methane
priority: normal
severity: normal
status: open
title: cgi.log() uses default encoding
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr  3 07:40:57 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 03 Apr 2021 11:40:57 +0000
Subject: [New-bugs-announce] [issue43712] PEP 597: fileinput uses locale
 encoding
Message-ID: <1617450057.65.0.948181942157.issue43712@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

fileinput.input() and fileinput.FileInput() don't have `encoding` parameter.

User can specify encoding by `openhook=hook_encoded("utf-8")`. But we can not utilize PEP 597, and `encoding="utf-8"` is more user friendly.

Additionally, `hook_compressed` doesn't have the encoding parameter. User need to use binary mode or locale encoding.

----------
components: Library (Lib)
messages: 390121
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: fileinput uses locale encoding
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr  3 08:33:39 2021
From: report at bugs.python.org (Tomer Kalish)
Date: Sat, 03 Apr 2021 12:33:39 +0000
Subject: [New-bugs-announce] [issue43713] sorted() signature is not accurate
 in the documentation
Message-ID: <1617453219.6.0.129506817169.issue43713@roundup.psfhosted.org>


New submission from Tomer Kalish <tomer.kalish91 at gmail.com>:

According to the docs, the sorted function's signature is:
sorted(iterable, *, key=None, reverse=False)
But when printing its help interactively, the signature is:
sorted(iterable, /, *, key=None, reverse=False)
The latter seems to be the correct one, as calling sorted(iterable=arr) will raise a TypeError.

The signature in the docs should be fixed.

----------
assignee: docs at python
components: Documentation
messages: 390122
nosy: docs at python, tomer.kalish91
priority: normal
severity: normal
status: open
title: sorted() signature is not accurate in the documentation
type: resource usage
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr  3 09:03:13 2021
From: report at bugs.python.org (Alexander Grigoriev)
Date: Sat, 03 Apr 2021 13:03:13 +0000
Subject: [New-bugs-announce] [issue43714] re.split(),
 re.sub(): '\Z' must consume end of string if it matched
Message-ID: <1617454993.35.0.466919552737.issue43714@roundup.psfhosted.org>


New submission from Alexander Grigoriev <alegrigoriev at gmail.com>:

If '\Z' matches as part of a pattern in re.sub() or re.split(), it should consume the end of string, and then '\Z' alone should not match the end of string again.

Current behavior:

Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> print(re.split(r'/?\Z', 'a/b/c/d/'))
['a/b/c/d', '', '']
>>> print(re.sub(r'/?\Z', '-', 'a/b/c/d/'))
a/b/c/d--


Wanted behavior:

>>> print(re.split(r'/?\Z', 'a/b/c/d/'))
['a/b/c/d', '']
>>> print(re.sub(r'/?\Z', '-', 'a/b/c/d/'))
a/b/c/d-

----------
components: Library (Lib)
messages: 390124
nosy: alegrigoriev
priority: normal
severity: normal
status: open
title: re.split(), re.sub(): '\Z' must consume end of string if it matched
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  3 15:22:03 2021
From: report at bugs.python.org (Peter J. Farley III)
Date: Sat, 03 Apr 2021 19:22:03 +0000
Subject: [New-bugs-announce] [issue43715] curses inch() and scrbkgd()
 documentation ommissions
Message-ID: <1617477723.19.0.381446769409.issue43715@roundup.psfhosted.org>


New submission from Peter J. Farley III <pjfarley3 at gmail.com>:

The documentation for the result values of curses functions inch() and scrbkgd() or how to use those result values are omitted entirely.  Documentation should at least describe how to use the result values of these functions without necessarily describing the actual format of the results, which do differ depending on the implementation of curses being used.

A suggestion for the documentation change is attached.

A separate issue will be filed questioning the need to shift the pair number result of the curses.pair_number() function in the Windows terminal environment.

----------
components: Extension Modules
files: curses-doc-change.txt
messages: 390136
nosy: pjfarleyiii
priority: normal
severity: normal
status: open
title: curses inch() and scrbkgd() documentation ommissions
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49930/curses-doc-change.txt

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

From report at bugs.python.org  Sat Apr  3 15:34:11 2021
From: report at bugs.python.org (Peter J. Farley III)
Date: Sat, 03 Apr 2021 19:34:11 +0000
Subject: [New-bugs-announce] [issue43716] curses.pair_number() function
 incorrect value under Windows
Message-ID: <1617478451.24.0.000946150268907.issue43716@roundup.psfhosted.org>


New submission from Peter J. Farley III <pjfarley3 at gmail.com>:

curses.pair_number() result under Windows (console or Terminal window) value must be shifted by 16 bits to be valid to use as input to the curses.pair_content() function.

If the pair number result is not shifted, the call to curses.pair_content() fails with an overflow error:

Traceback (most recent call last):
  File "C:\Users\MyUser\test\curses-color.py", line 126, in <module>
    curses.wrapper(main)
  File "C:\Python38\lib\curses\__init__.py", line 105, in wrapper
    return func(stdscr, *args, **kwds)
  File "C:\Users\MyUser\test\curses-color.py", line 72, in main
    fg, bg = curses.pair_content (pair)
OverflowError: signed short integer is greater than maximum

The attached curses program demonstrates the correct functioning using the pair value shift under Windows.  Comment out the "if" and shift lines to reproduce the overflow error.

Environment information:

Windows 10 (latest updates)
Windows cmd.exe window or Windows Terminal Version: 1.6.10571.0
Python 3.8.7
windows-curses 2.2.0

Also tested in:

Ubuntu 20.04 (WSL2)
ncurses6/focal,now 6.2-0ubuntu2 amd64

----------
components: Extension Modules
files: curses-color-1.py
messages: 390137
nosy: pjfarleyiii
priority: normal
severity: normal
status: open
title: curses.pair_number() function incorrect value under Windows
versions: Python 3.8
Added file: https://bugs.python.org/file49931/curses-color-1.py

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

From report at bugs.python.org  Sat Apr  3 15:38:31 2021
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 03 Apr 2021 19:38:31 +0000
Subject: [New-bugs-announce] [issue43717] Confusing OSError on HTTP CONNECT
 failure
Message-ID: <1617478711.42.0.190186682039.issue43717@roundup.psfhosted.org>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

When working with proxies and HTTP CONNECT I came across these lines: https://github.com/python/cpython/blob/63c69440c7adb0de1d191a8d3d100b335d5c2f81/Lib/http/client.py#L901-L903

I truly fail to see why this is an OSError. OSErrors (https://docs.python.org/3/library/exceptions.html#os-exceptions) describe a low-level issues, but HTTP is a high level protocol. I would expect something like NotConnected or at least something which derives from HTTPException.

OSError is expected on socket issues only.

----------
components: Library (Lib)
messages: 390138
nosy: michael-o
priority: normal
severity: normal
status: open
title: Confusing OSError on HTTP CONNECT failure
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  3 15:45:12 2021
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 03 Apr 2021 19:45:12 +0000
Subject: [New-bugs-announce] [issue43718] HTTP CONNECT response not subject
 to debug level
Message-ID: <1617479112.59.0.978864196695.issue43718@roundup.psfhosted.org>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

Looking at https://github.com/python/cpython/blob/63c69440c7adb0de1d191a8d3d100b335d5c2f81/Lib/http/client.py#L898
self.debuglevel is not passed to response_class() and for debugging purposes I miss to see:
> send: b'CONNECT some-host:443 HTTP/1.0\r\n'
> send: b'\r\n'
> reply: 'HTTP/1.0 502 Bad Gateway\r\n'

reply is missing. It trivial to pass the debug level.

----------
components: Library (Lib)
messages: 390139
nosy: michael-o
priority: normal
severity: normal
status: open
title: HTTP CONNECT response not subject to debug level
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr  3 16:15:48 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Apr 2021 20:15:48 +0000
Subject: [New-bugs-announce] [issue43719] Master build failure on Windows
 getting file system encoding
Message-ID: <1617480948.24.0.651940029044.issue43719@roundup.psfhosted.org>


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

After a fresh update from upstream
> PCbuild\build.bat -D (or without -D)
on my machine ends with

  python.vcxproj -> f:\dev\3x\PCbuild\amd64\python_d.pdb (Full PDB)
  Python path configuration:
    PYTHONHOME = (not set)
    PYTHONPATH = 'f:\dev\3x\Lib'
    program name = 'f:\dev\3x\PCbuild\amd64\python_d.exe'
    isolated = 0
    environment = 1
    user site = 1
    import site = 1
    sys._base_executable = 'f:\\dev\\3x\\PCbuild\\amd64\\python_d.exe'
    sys.base_prefix = 'f:\\dev\\3x'
    sys.base_exec_prefix = 'f:\\dev\\3x'
    sys.platlibdir = 'lib'
    sys.executable = 'f:\\dev\\3x\\PCbuild\\amd64\\python_d.exe'
    sys.prefix = 'f:\\dev\\3x'
    sys.exec_prefix = 'f:\\dev\\3x'
    sys.path = [
      'f:\\dev\\3x\\Lib',
      'f:\\dev\\3x\\PCbuild\\amd64\\python310_d.zip',
      'f:\\dev\\3x\\DLLs',
      'f:\\dev\\3x\\lib',
      'f:\\dev\\3x\\PCbuild\\amd64',
    ]
EXEC : Fatal Python warning : init_fs_encoding: failed to get the Python codec
of the filesystem encoding [f:\dev\3x\PCbuild\python.vcxproj]
  Python runtime state: core initialized
  Traceback (most recent call last):
    File "f:\dev\3x\Lib\encodings\__init__.py", line 31, in <module>
f:\dev\3x\PCbuild\python.vcxproj(123,5): warning MSB3073: The command "setlocal
\r
f:\dev\3x\PCbuild\python.vcxproj(123,5): warning MSB3073: set PYTHONPATH=f:\dev
\3x\Lib\r
f:\dev\3x\PCbuild\python.vcxproj(123,5): warning MSB3073: "f:\dev\3x\PCbuild\am
d64\python_d.exe" "f:\dev\3x\PC\validate_ucrtbase.py" ucrtbased" exited with co
de -1073741819.
  pythonw.vcxproj -> f:\dev\3x\PCbuild\amd64\pythonw_d.exe
  pythonw.vcxproj -> f:\dev\3x\PCbuild\amd64\pythonw_d.pdb (Full PDB)

EXEC : Fatal Python warning : init_fs_encoding: failed to get the Python codec
of the filesystem encoding [f:\dev\3x\PCbuild\python.vcxproj]
f:\dev\3x\PCbuild\python.vcxproj(123,5): warning MSB3073: The command "setlocal
\r
f:\dev\3x\PCbuild\python.vcxproj(123,5): warning MSB3073: set PYTHONPATH=f:\dev
\3x\Lib\r
f:\dev\3x\PCbuild\python.vcxproj(123,5): warning MSB3073: "f:\dev\3x\PCbuild\am
d64\python_d.exe" "f:\dev\3x\PC\validate_ucrtbase.py" ucrtbased" exited with co
de -1073741819.

I believe I pulled and rebuilt fine just a few days ago. Subsequently running
> python
ends with

Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
Traceback (most recent call last):
  File "f:\dev\3x\\lib\encodings\__init__.py", line 31, in <module>

Running > chkdsk F: /scan revealed no obvious disk error, but there could be corrupted bytes in some file, but I don't know what file(s) to check (if text) or delete and have git redownload.  Anyone else have a similar problem?

----------
components: Build, Windows
keywords: 3.10regression
messages: 390140
nosy: pablogsal, paul.moore, steve.dower, terry.reedy, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Master build failure on Windows getting file system encoding
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr  3 16:45:08 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Apr 2021 20:45:08 +0000
Subject: [New-bugs-announce] [issue43720] Document various preexisting
 stdlib deprecations related to import for removal in Python 3.12
Message-ID: <1617482708.53.0.134596819215.issue43720@roundup.psfhosted.org>


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

The following module's have preexisting deprecations with no slated removal version. Since so much of import is getting cleaned up in Python 3.12, these should finally go as well so the APIs are consistent across Python.

- imp
- pkgutil
- importlib.util

----------
assignee: brett.cannon
components: Library (Lib)
messages: 390141
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Document various preexisting stdlib deprecations related to import for removal in Python 3.12
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr  3 19:10:19 2021
From: report at bugs.python.org (Antony Lee)
Date: Sat, 03 Apr 2021 23:10:19 +0000
Subject: [New-bugs-announce] [issue43721] Documentation of property.{getter,
 setter, deleter} fails to mention that a *new* property is returned
Message-ID: <1617491419.64.0.547160681333.issue43721@roundup.psfhosted.org>


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

property.{getter,setter,deleter} returns a new property with a new {fget,fset,fdel}.  This is documented at https://docs.python.org/3/library/functions.html#property, and intended behavior (see e.g. https://bugs.python.org/issue1620).

However the corresponding docstrings, e.g. `pydoc property.getter`, are "Descriptor to change the getter (setter, deleter) on a property."  This wording suggests that no copy is being made and that the property is mutated in-place.

----------
assignee: docs at python
components: Documentation
messages: 390149
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Documentation of property.{getter,setter,deleter} fails to mention that a *new* property is returned

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

From report at bugs.python.org  Sat Apr  3 20:21:58 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 04 Apr 2021 00:21:58 +0000
Subject: [New-bugs-announce] [issue43722] PEP 597: FileCookieJar uses locale
 encoding
Message-ID: <1617495718.2.0.60661799695.issue43722@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

During fixing EncodingWarning in stdlibs, I found FileCookieJar, LWPCookieJar, and MozillaCookieJar use locale encoding for cookie files.

I don't know much about cookie file format. If locale encoding is right encoding, we can just use `encoding="locale"` since Python 3.10.

Or cookie files should be encoded in UTF-8, or latin-1?

----------
components: Library (Lib)
messages: 390160
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: FileCookieJar uses locale encoding
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr  3 21:01:50 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 04 Apr 2021 01:01:50 +0000
Subject: [New-bugs-announce] [issue43723] Deprecate camelCase aliases from
 threading.py
Message-ID: <1617498110.97.0.827656186074.issue43723@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

Followup from issue37804: deprecate the remaining camelCase aliases, such as threading.currentThread. PR coming soon.

----------
assignee: Jelle Zijlstra
components: Library (Lib)
messages: 390165
nosy: Jelle Zijlstra, pitrou
priority: normal
severity: normal
status: open
title: Deprecate camelCase aliases from threading.py
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr  3 22:51:14 2021
From: report at bugs.python.org (Allen)
Date: Sun, 04 Apr 2021 02:51:14 +0000
Subject: [New-bugs-announce] [issue43724] cannot compute sizeof (long double)
Message-ID: <1617504674.05.0.0692778789598.issue43724@roundup.psfhosted.org>


Change by Allen <allen.lili at hotmail.com>:


----------
files: config.log
nosy: allenlili
priority: normal
severity: normal
status: open
title: cannot compute sizeof (long double)
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file49933/config.log

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

From report at bugs.python.org  Sun Apr  4 00:35:13 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 04 Apr 2021 04:35:13 +0000
Subject: [New-bugs-announce] [issue43725] Create a release branch ABI
 stability regression test
Message-ID: <1617510913.58.0.992460597619.issue43725@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

In order to automate prevention of ABI regressions in stable releases, we could create an automated ABI stability test generator and check the specific ABI test it generates into each specific release branch.

I'm envisioning the main branch only having a code generator that creates such a test, and the release branches only having the output of that as Lib/tests/release_X_Y_ABI_stability_test.py and a policy of never updating that within a release branch without *extreme* attention to detail.

Such updates wouldn't happen by default in our current workflow as they're unique and versioned in every release branch so automated backport PRs wouldn't touch them - leaving CI to run them and highlight failures on attempted backports to do inadvertently cause an ABI shift.

----------
components: Build, C API, Interpreter Core, Tests
messages: 390173
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Create a release branch ABI stability regression test
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr  4 03:52:01 2021
From: report at bugs.python.org (David Ellsworth)
Date: Sun, 04 Apr 2021 07:52:01 +0000
Subject: [New-bugs-announce] [issue43726] regex module fails with a
 quantified backref but succeeds with repeated backref
Message-ID: <1617522721.12.0.340315705312.issue43726@roundup.psfhosted.org>


New submission from David Ellsworth <davidell at earthling.net>:

The regex /^((x*)\2{3}(?=\2$))*x$/ matches powers of 5 in unary, expressed as strings of "x" characters whose length is the number.

The following command line should print "1", but prints nothing:
python -c 'import regex; regex.match(r"^((x*)\2{3}(?=\2$))*x$", "x"*125) and print(1)'

However, this command does print "1":
python -c 'import regex; regex.match(r"^((x*)\2\2\2(?=\2$))*x$", "x"*125) and print(1)'

And so does this one:
python -c 'import re; re.match(r"^((x*)\2{3}(?=\2$))*x$", "x"*125) and print(1)'

The expression "\2\2\2" should behave exactly the same as "\2{3}", but in the "regex" module it does not.

Solving the following Code Golf Stack Exchange challenge is what led me to discover this bug:
https://codegolf.stackexchange.com/questions/211840/is-that-number-a-two-bit-number%ef%b8%8f/222792#222792

----------
components: Regular Expressions
messages: 390175
nosy: Davidebyzero, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: regex module fails with a quantified backref but succeeds with repeated backref
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Apr  4 07:59:46 2021
From: report at bugs.python.org (bbh)
Date: Sun, 04 Apr 2021 11:59:46 +0000
Subject: [New-bugs-announce] [issue43727] futures cancelled by
 ThreadPoolExecutor.shutdown() not yielded by as_completed()
Message-ID: <1617537586.46.0.369484002323.issue43727@roundup.psfhosted.org>


New submission from bbh <benj.luethi at gmx.net>:

concurrent.futures.ThreadPoolExecutor.shutdown(cancel_futures=True) cancels the pending futures, but the futures remain in the state CANCELLED and never get to the state CANCELLED_AND_NOTIFIED. Thus they are never yielded by concurrent.futures.as_completed().

If I use shutdown(cancel_futures=True) in a loop of as_completed(), the loop will never finish and the program hangs. Not even Ctrl-C works.

If I use concurrent.futures.Future.cancel() on all pending futures in the loop, everything works as expected.

----------
components: Library (Lib)
messages: 390183
nosy: bigbenhur
priority: normal
severity: normal
status: open
title: futures cancelled by ThreadPoolExecutor.shutdown() not yielded by as_completed()
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr  4 11:17:03 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Sun, 04 Apr 2021 15:17:03 +0000
Subject: [New-bugs-announce] [issue43728] Change the exception type and
 message raised when _curses is not found.
Message-ID: <1617549423.3.0.901195728077.issue43728@roundup.psfhosted.org>


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

When importing the curses module, be it on Windows or Darwin or UNIX-based OS or any other platform, if the _curses module is not found then just a ModuleNotFoundError is raised. But this error is not very informational in case of _curses module. Since the curses module is packaged with the Python interpreter itself at first it may seem, to beginners especially, that the Python interpreter was not installed correctly and then they would go searching for an answer for about 4-5 days. 

We know that curses library is not installed on windows by default and may or may not be present on other operating systems. Most UNIX system have ncurses or other curses library installed by default. 

Python errors have a reputation of being very informational. I would like to submit a PR to modify the curses module a little bit by declaring a BaseException class and raising that Exception with the message "_curses module not found. Make sure a curses library is installed" or some kind of message like that.

But before I do that I would like to take advice from experienced developers about somethings. Is this change in the exception, raised when _curses module is not found, acceptable by the Python Community? If it is then should a draft PEP be submitted or should a PR be directly submitted to python/cpython?

----------
components: Library (Lib)
messages: 390195
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Change the exception type and message raised when _curses is not found.
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun Apr  4 19:44:25 2021
From: report at bugs.python.org (Thomas Cavalli)
Date: Sun, 04 Apr 2021 23:44:25 +0000
Subject: [New-bugs-announce] [issue43729] Tutorial Documentation for 3.1.1.
 Numbers missing "result"
Message-ID: <1617579865.45.0.541169648182.issue43729@roundup.psfhosted.org>


New submission from Thomas Cavalli <thomaspcavalli at gmail.com>:

The Division (/) section example uses the commented variable "result" without it being defined.  I am counting 4 numbers, (5.6667, 5, 2, 17), that are called result. The correct result can be implied but its poor documentation. So, either change:
>>> 17 // 3   # floor division discards the fractional part
to
>>> result = 17 // 3   # floor division discards the fractional part

or change:
>>> 5 * 3 + 2   # result * divisor + remainder
to
>>> 5 * 3 + 2  # floor * divisor + remainder

I suggest the latter as it explains the formula for floor.

----------
assignee: docs at python
components: Documentation
messages: 390217
nosy: docs at python, thomaspcavalli
priority: normal
severity: normal
status: open
title: Tutorial Documentation for 3.1.1. Numbers missing "result"
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr  4 20:59:54 2021
From: report at bugs.python.org (Thomas Cavalli)
Date: Mon, 05 Apr 2021 00:59:54 +0000
Subject: [New-bugs-announce] [issue43730] Tutorial Documentation for
 4.7.3.2. Positional-Only Parameters, no "/" ques
Message-ID: <1617584394.44.0.298702006886.issue43730@roundup.psfhosted.org>


Change by Thomas Cavalli <thomaspcavalli at gmail.com>:


----------
nosy: thomaspcavalli
priority: normal
severity: normal
status: open
title: Tutorial Documentation for 4.7.3.2. Positional-Only Parameters,   no "/" ques

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

From report at bugs.python.org  Mon Apr  5 00:29:28 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 05 Apr 2021 04:29:28 +0000
Subject: [New-bugs-announce] [issue43731] PEP 597: logging.basicConfig()
 uses locale encoding.
Message-ID: <1617596968.06.0.267322224871.issue43731@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

logging.basicConfig() uses locale encoding when reading config file.

We need to add `encoding=None` parameter and `encoding=io.text_encoding(encoding)` in it.

----------
components: Library (Lib)
messages: 390223
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: logging.basicConfig() uses locale encoding.
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr  5 08:35:59 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 05 Apr 2021 12:35:59 +0000
Subject: [New-bugs-announce] [issue43732] PEP 597: mailcap uses locale
 encoding
Message-ID: <1617626159.89.0.666566758003.issue43732@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

mailcap.getcaps() uses locale encoding.
https://github.com/python/cpython/blob/c8e5eb904e12010d2302364e1037c24a30f5e241/Lib/mailcap.py#L33

As my understanding, RFC 1524 uses only ASCII characters.
Can we change the encoding to ASCII or UTF-8?

----------
components: Library (Lib)
messages: 390231
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: mailcap uses locale encoding
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr  5 08:46:50 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 05 Apr 2021 12:46:50 +0000
Subject: [New-bugs-announce] [issue43733] PEP 597: netrc uses locale
 encoding.
Message-ID: <1617626810.53.0.0987972947565.issue43733@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

https://github.com/python/cpython/blob/c8e5eb904e12010d2302364e1037c24a30f5e241/Lib/netrc.py#L29

Can we change the encoding="utf-8" and errors="replace"?

IMHO, comments are source of UnicodeDecodeError. So we can open file with binary mode and skip comments without decoding it.
But we need to decode non-comment lines lines with some encoding anyway.

----------
components: Library (Lib)
messages: 390232
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: netrc uses locale encoding.
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr  5 08:57:55 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 05 Apr 2021 12:57:55 +0000
Subject: [New-bugs-announce] [issue43734] PEP 597: pdb uses locale encoding
 for pdbrc file
Message-ID: <1617627475.28.0.0123915505564.issue43734@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

I think we should use UTF-8 for pdbrc files because the default encoding of Python source files is UTF-8.

----------
components: Library (Lib)
messages: 390233
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: pdb uses locale encoding for pdbrc file
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr  5 09:28:22 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 05 Apr 2021 13:28:22 +0000
Subject: [New-bugs-announce] [issue43735] os.popen() and pipes uses locale
 encoding
Message-ID: <1617629302.16.0.0682743607407.issue43735@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

os.popen() and pipes module doesn't have `encoding` parameter. They use the default (locale) encoding implicitly.

As PEP 597, subprocess module won't emit EncodingWarning for PIPEs in Python 3.10.
Like that, we should just add `encoding=None` parameter but don't emit  EncodingWarning.

----------
components: Library (Lib)
messages: 390234
nosy: methane
priority: normal
severity: normal
status: open
title: os.popen() and pipes uses locale encoding
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr  5 17:03:00 2021
From: report at bugs.python.org (Yanghao Hua)
Date: Mon, 05 Apr 2021 21:03:00 +0000
Subject: [New-bugs-announce] [issue43736] asyncio create_task() odd behavior
Message-ID: <1617656580.62.0.948466534657.issue43736@roundup.psfhosted.org>


New submission from Yanghao Hua <yanghao.py at gmail.com>:

This code runs perfectly fine with expected behavior: two tasks created, executed in an interleaved manner:

from time import time
from asyncio import run, create_task, sleep

async def task(name, n): 
    for i in range(n):
        print(f"task-{name}: ", i, time())
        await sleep(1)

async def top():
    t0 = create_task(task("T0", 10))
    t1 = create_task(task("T1", 10))
    print("starting tasks ...")
    await t0
    await t1

run(top())

Output:
starting tasks ...
task-T0:  0 1617656271.6513114
task-T1:  0 1617656271.6513336
task-T0:  1 1617656272.6526577
task-T1:  1 1617656272.652813
task-T0:  2 1617656273.654187
task-T1:  2 1617656273.6543217
task-T0:  3 1617656274.655706
task-T1:  3 1617656274.6558387
task-T0:  4 1617656275.65722
task-T1:  4 1617656275.657355
task-T0:  5 1617656276.6587365
task-T1:  5 1617656276.6588728
task-T0:  6 1617656277.660276
task-T1:  6 1617656277.6604114
task-T0:  7 1617656278.6617858
task-T1:  7 1617656278.66192
task-T0:  8 1617656279.6633058
task-T1:  8 1617656279.6634388
task-T0:  9 1617656280.6648436
task-T1:  9 1617656280.6649704

However, with slightly modified `async def top()`, things become executing sequentially:

async def top():
    print("starting tasks ...")
    await create_task(task("T0", 10))
    await create_task(task("T1", 10))

Output:
starting tasks ...
task-T0:  0 1617656306.1343822
task-T0:  1 1617656307.1357212
task-T0:  2 1617656308.1369958
task-T0:  3 1617656309.1384225
task-T0:  4 1617656310.1398354
task-T0:  5 1617656311.1412706
task-T0:  6 1617656312.1427014
task-T0:  7 1617656313.1441336
task-T0:  8 1617656314.1455553
task-T0:  9 1617656315.1468768
task-T1:  0 1617656316.1482618
task-T1:  1 1617656317.1496553
task-T1:  2 1617656318.151089
task-T1:  3 1617656319.1525192
task-T1:  4 1617656320.153974
task-T1:  5 1617656321.1554224
task-T1:  6 1617656322.1568594
task-T1:  7 1617656323.1582792
task-T1:  8 1617656324.1597185
task-T1:  9 1617656325.1611636

This breaks the behavior expectation, where created tasks should have been executing in parallel. It seems if a created task is immediately awaited, it is not returning to the top() immediately, and instead, it executes the task and waited until it finishes.

Is this a bug, or did I miss something?

Thank you.

----------
components: asyncio
messages: 390260
nosy: asvetlov, yanghao.py, yselivanov
priority: normal
severity: normal
status: open
title: asyncio create_task() odd behavior
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr  5 17:49:56 2021
From: report at bugs.python.org (Anthony Flury)
Date: Mon, 05 Apr 2021 21:49:56 +0000
Subject: [New-bugs-announce] [issue43737] Documentation of modulo operator
 should document behaviour clearly when second operator is negative
Message-ID: <1617659396.43.0.525762996462.issue43737@roundup.psfhosted.org>


New submission from Anthony Flury <anthony.flury at btinternet.com>:

The behavior of a%b when a is positive and b is negative can be suprising. 

I understand that the behavior is so that the identity 

a = (a//b)*b + a%b 

can be preserved regardless of the signs of a or b.

but the result is different from other languages which is why it can be surprising.

I would be happy to do the grunt work to make the changes if some can suggest where.

Do we - add a warning to the https://docs.python.org/3/tutorial/introduction.html#numbers page, or should we link to a new page that details and explains the behavior. Which is more 'pythonic' in terms of documentation ?

----------
messages: 390264
nosy: anthony-flury
priority: normal
severity: normal
status: open
title: Documentation of modulo operator should document behaviour clearly when second operator is negative

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

From report at bugs.python.org  Mon Apr  5 19:37:41 2021
From: report at bugs.python.org (Ryan McCampbell)
Date: Mon, 05 Apr 2021 23:37:41 +0000
Subject: [New-bugs-announce] [issue43738] Clarify public name of
 curses.window
Message-ID: <1617665861.34.0.620299558452.issue43738@roundup.psfhosted.org>


New submission from Ryan McCampbell <rmccampbell7 at gmail.com>:

Until 3.8 the curses window class was not directly available in code, but now it is available as `_curses.window`. This is not explicitly stated in the documentation (although it is consistent with how the method signatures are written). It is useful to have a public name for the type to aid IDE's with explicit type annotations, i.e.

@curses.wrapper
def main(stdscr: curses.window):
    stdscr.addstr(...)

See https://github.com/python/typeshed/pull/5180, which adds this name to type hints in the typeshed project.

This name should be more clearly documented so programmers can annotate the type without worrying that it may change (which will cause a runtime error unless it is quoted).

----------
assignee: docs at python
components: Documentation
messages: 390266
nosy: docs at python, rmccampbell7
priority: normal
severity: normal
status: open
title: Clarify public name of curses.window
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Apr  6 02:37:16 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Tue, 06 Apr 2021 06:37:16 +0000
Subject: [New-bugs-announce] [issue43739] Fixing the example code in
 Doc/extending/extending.rst to declare and initialize the pmodule variable
 to be of the right type.
Message-ID: <1617691036.34.0.606106237271.issue43739@roundup.psfhosted.org>


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

In the example code of the Extending Python with C/C++ documentation the pmodule variable (that stores the return value of PyImport_ImportModule) was never declared. The PR(s) attached to this issue fixes it by declaring and initializing the pmodule variable. This issue is common in all the documentation versions. The first PR will be for documentation version 3.10. If it's accepted then I would request other developers to submit PRs for documentation 3.9, 3.8, 3.7 and 3.6 because I'm having a problem switching to those branches (I'm continuously facing the problem "HEAD detached" if I switch to those branches).

Thanking you

With Regards

----------
assignee: docs at python
components: Documentation
messages: 390281
nosy: docs at python, shreyanavigyan
priority: normal
severity: normal
status: open
title: Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
type: compile error
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr  6 03:11:07 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 06 Apr 2021 07:11:07 +0000
Subject: [New-bugs-announce] [issue43740] Long paths in imp.load_dynamic()
 lead to segfault
Message-ID: <1617693067.85.0.367644803477.issue43740@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Long paths as arguments of imp.load_dynamic() lead to interpreter crashes.

Crash example
=====================================================
Python 3.10.0a2 (default, Nov 24 2020, 14:18:46)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp
>>> imp.load_dynamic('',"abs/"*10000000)
Segmentation fault (core dumped)
======================================================

Environment:
Ubuntu 16.04, Python 3.92, Python 3.10.0a2
Mac OS Big Sur 11.2.3, Python 3.91, Python 3.10.0a2


Testing with gdb
-------------------------------------------------------------------------------------
$gdb ./python
(gdb) run 
Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp
>>> imp.load_dynamic('','abs/'*100000000)
Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../sysdeps/x86_64/multiarch/../memcpy.S:272
272 ../sysdeps/x86_64/multiarch/../memcpy.S: No such file or directory.




Testing with valgrind
-------------------------------------------------------------------------------------
xxm at xxm-System-Product-Name:~$ PYTHONMALLOC=malloc_debug valgrind '/home/xxm/Desktop/apifuzz/Python-3.10.0a6/python'
==4923== Memcheck, a memory error detector
==4923== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4923== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==4923== Command: /home/xxm/Desktop/apifuzz/Python-3.10.0a6/python
==4923==
Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.dgettext('abs'*10,'')
''
>>> import imp
<stdin>:1: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
>>> imp.load_dynamic('','abs/'*100000000)
==4923== Warning: set address range perms: large range [0x8037040, 0x1fdaf489) (undefined)
==4923== Warning: set address range perms: large range [0x1fdb0040, 0x37b28479) (undefined)
==4923== Warning: set address range perms: large range [0x37b29040, 0x4f8a1441) (undefined)
==4923== Warning: set address range perms: large range [0x37b29028, 0x4f8a1459) (noaccess)
==4923== Warning: set address range perms: large range [0x59eb3040, 0x71c2b460) (undefined)
==4923== Warning: client switching stacks? SP change: 0x1ffeffe460 --> 0x1fe7286028
==4923== to suppress, use: --max-stackframe=400000056 or greater
==4923== Invalid write of size 8
==4923== at 0x401513F: _dl_open (dl-open.c:701)
==4923== Address 0x1fe7286028 is on thread 1's stack
==4923==
==4923==
==4923== Process terminating with default action of signal 11 (SIGSEGV)
==4923== Access not within mapped region at address 0x1FE7286028
==4923== at 0x401513F: _dl_open (dl-open.c:701)
==4923== If you believe this happened as a result of a stack
==4923== overflow in your program's main thread (unlikely but
==4923== possible), you can try to increase the size of the
==4923== main thread stack using the --main-stacksize= flag.
==4923== The main thread stack size used in this run was 8388608.
==4923== Invalid write of size 8
==4923== at 0x4A2867A: _vgnU_freeres (vg_preloaded.c:57)
==4923== Address 0x1fe7286020 is on thread 1's stack
==4923==
==4923==
==4923== Process terminating with default action of signal 11 (SIGSEGV)
==4923== Access not within mapped region at address 0x1FE7286020
==4923== at 0x4A2867A: _vgnU_freeres (vg_preloaded.c:57)
==4923== If you believe this happened as a result of a stack
==4923== overflow in your program's main thread (unlikely but
==4923== possible), you can try to increase the size of the
==4923== main thread stack using the --main-stacksize= flag.
==4923== The main thread stack size used in this run was 8388608.
==4923==
==4923== HEAP SUMMARY:
==4923== in use at exit: 1,205,374,369 bytes in 36,250 blocks
==4923== total heap usage: 96,421 allocs, 60,171 frees, 1,616,393,081 bytes allocated
==4923==
==4923== LEAK SUMMARY:
==4923== definitely lost: 0 bytes in 0 blocks
==4923== indirectly lost: 0 bytes in 0 blocks
==4923== possibly lost: 805,237,234 bytes in 35,439 blocks
==4923== still reachable: 400,137,135 bytes in 811 blocks
==4923== suppressed: 0 bytes in 0 blocks
==4923== Rerun with --leak-check=full to see details of leaked memory
==4923==
==4923== For lists of detected and suppressed errors, rerun with: -s
==4923== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

----------
components: Library (Lib)
messages: 390284
nosy: xxm
priority: normal
severity: normal
status: open
title: Long paths in imp.load_dynamic()  lead to segfault
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 03:43:38 2021
From: report at bugs.python.org (Hynek Petrak)
Date: Tue, 06 Apr 2021 07:43:38 +0000
Subject: [New-bugs-announce] [issue43741] http.client leaks from
 self.fp.read()
Message-ID: <1617695018.24.0.921353674575.issue43741@roundup.psfhosted.org>


New submission from Hynek Petrak <hynek.petrak at gmail.com>:

Hi, I wrote an webcrawler, which is using ThreadPoolExecutor to span multiple thread workers, retrieve content of a web using via http.client and saves it to a file.
After a couple of thousands requests have been processes, the crawler starts to consume memory rapidly, resulting in consumption of all available memory.
tracemalloc shows the memory is not collected from:
/usr/lib/python3.9/http/client.py:468: size=47.6 MiB, count=6078, average=8221 B
  File "/usr/lib/python3.9/http/client.py", line 468
    s = self.fp.read()

I have tested as well with requests and urllib3 and as they use http.client underneath, the result is always the same.

My code around that:
def get_html3(session, url, timeout=10):
    o = urlparse(url)
    if o.scheme == 'http':
        cn = http.client.HTTPConnection(o.netloc, timeout=timeout)
    else:
        cn = http.client.HTTPSConnection(o.netloc, context=ctx, timeout=timeout)
    cn.request('GET', o.path, headers=headers)
    r = cn.getresponse()
    log.debug(f'[*] [{url}] Status: {r.status} {r.reason}')
    if r.status not in [400, 403, 404]:
        ret = r.read().decode('utf-8')
    else:
        ret = ""
    r.close()
    del r
    cn.close()
    del cn
    return ret

----------
messages: 390287
nosy: HynekPetrak
priority: normal
severity: normal
status: open
title: http.client leaks from self.fp.read()
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr  6 04:07:33 2021
From: report at bugs.python.org (julian colomina)
Date: Tue, 06 Apr 2021 08:07:33 +0000
Subject: [New-bugs-announce] [issue43742] tcp_echo_client in asyncio streams
 example does not work. Hangs for ever at reaser.read()
Message-ID: <1617696453.27.0.575129983051.issue43742@roundup.psfhosted.org>


New submission from julian colomina <julcol33 at gmail.com>:

taking the example verbatim into an ubuntu 20.04 with
 Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux

will hand indefinitely at 
data = await reader.read(100)

changing for 
data = await asyncio.wait_for(reader.read(100),5)

will always leave on timeout.

----------
components: asyncio
messages: 390295
nosy: asvetlov, jcolo, yselivanov
priority: normal
severity: normal
status: open
title: tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read()
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr  6 04:21:31 2021
From: report at bugs.python.org (Pablo Conesa)
Date: Tue, 06 Apr 2021 08:21:31 +0000
Subject: [New-bugs-announce] [issue43743] BlockingIOError: [Errno 11]
 Resource temporarily unavailable: on GPFS.
Message-ID: <1617697291.82.0.0904085621091.issue43743@roundup.psfhosted.org>


New submission from Pablo Conesa <p.conesa.mingo at gmail.com>:

Hi, one of our users is reporting this starting to happen in a GPFS. All has been working fine for NTFS so far for many years.

I had a look at my shutil code, and I can see the try/except code trying to fall back to the "slower" copyfileobj(fsrc, fdst).

But it seems, by the stacktrace bellow that the "catch" is not happening.

Any idea how to fix this?

I guess something like:

import shutil
shutil._USE_CP_SENDFILE = False

should avoid the fast_copy attempt.



> Traceback (most recent call last):
>   File "/opt/pxsoft/scipion/v3/ubuntu20.04/scipion-em-esrf/esrf/workflow/esrf_launch_workflow.py", line 432, in <module>
>     project.scheduleProtocol(prot)
>   File "/opt/pxsoft/scipion/v3/ubuntu20.04/anaconda3/envs/.scipion3env/lib/python3.8/site-packages/pyworkflow/project/project.py", line 633, in scheduleProtocol
>     pwutils.path.copyFile(self.dbPath, protocol.getDbPath())
>   File "/opt/px/scipion/v3/ubuntu20.04/anaconda3/envs/.scipion3env/lib/python3.8/site-packages/pyworkflow/utils/path.py", line 247, in copyFile
>     shutil.copy(source, dest)
>   File "/opt/pxsoft/scipion/v3/ubuntu20.04/anaconda3/envs/.scipion3env/lib/python3.8/shutil.py", line 415, in copy
>     copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/opt/pxsoft/scipion/v3/ubuntu20.04/anaconda3/envs/.scipion3env/lib/python3.8/shutil.py", line 272, in copyfile
>     _fastcopy_sendfile(fsrc, fdst)
>   File "/opt/pxsoft/scipion/v3/ubuntu20.04/anaconda3/envs/.scipion3env/lib/python3.8/shutil.py", line 169, in _fastcopy_sendfile
>     raise err
>   File "/opt/pxsoft/scipion/v3/ubuntu20.04/anaconda3/envs/.scipion3env/lib/python3.8/shutil.py", line 149, in _fastcopy_sendfile
>     sent = os.sendfile(outfd, infd, offset, blocksize)
> BlockingIOError: [Errno 11] Resource temporarily unavailable: 'project.sqlite' -> 'Runs/000002_ProtImportMovies/logs/run.db'

----------
components: IO
messages: 390297
nosy: p.conesa.mingo
priority: normal
severity: normal
status: open
title: BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr  6 05:16:25 2021
From: report at bugs.python.org (Matthias Urlichs)
Date: Tue, 06 Apr 2021 09:16:25 +0000
Subject: [New-bugs-announce] [issue43744] enum: Adding a var named
 _anything__ raises IndexError
Message-ID: <1617700585.14.0.506924714072.issue43744@roundup.psfhosted.org>


New submission from Matthias Urlichs <matthias at urlichs.de>:

While checking out the Enum implementation I noticed that this code snippet results in an IndexError.

I have no idea which error or warning (if any) this should generate instead. Opinions?

    import enum
    class duh(enum.Enum):
        _duh__ = "moo"

----------
components: Library (Lib)
messages: 390301
nosy: smurfix
priority: normal
severity: normal
status: open
title: enum: Adding a var named _anything__ raises IndexError
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 06:23:58 2021
From: report at bugs.python.org (Bill Collins)
Date: Tue, 06 Apr 2021 10:23:58 +0000
Subject: [New-bugs-announce] [issue43745] ssl.OPENSSL_VERSION still
 reporting 1.1.1i on windows 3.8.9/3.9.4
Message-ID: <1617704638.47.0.609458231691.issue43745@roundup.psfhosted.org>


New submission from Bill Collins <bilbocollins at gmail.com>:

>>> import sys,ssl
>>> sys.version
'3.9.4 (tags/v3.9.4:1f2e308, Apr  4 2021, 13:27:16) [MSC v.1928 64 bit (AMD64)]'
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.1i  8 Dec 2020'

I may well be holding it wrong, but something seems off.

----------
components: Windows
messages: 390303
nosy: Bill Collins, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ssl.OPENSSL_VERSION still reporting 1.1.1i on windows 3.8.9/3.9.4
type: security
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr  6 06:37:43 2021
From: report at bugs.python.org (conchylicultor)
Date: Tue, 06 Apr 2021 10:37:43 +0000
Subject: [New-bugs-announce] [issue43746] Weird typing annotation closure
 behavior
Message-ID: <1617705463.18.0.247710543326.issue43746@roundup.psfhosted.org>


New submission from conchylicultor <etiennefg.pot at gmail.com>:

I observe some strange closure behavior for typing annotations when the name is defined

```
x: x = 1  # Works, __annotation__ == {'x': 1}
```

This creates issue, for example:

```
from ... import losses

class A:
  # AttributeError: 'Losses' object has no attribute 'Losses'
  losses: losses.Losses = losses.Losses()
```

----------
messages: 390304
nosy: conchylicultor
priority: normal
severity: normal
status: open
title: Weird typing annotation closure behavior

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

From report at bugs.python.org  Tue Apr  6 08:22:14 2021
From: report at bugs.python.org (Kun He)
Date: Tue, 06 Apr 2021 12:22:14 +0000
Subject: [New-bugs-announce] [issue43747] Can't create new interpreter in
 multi thread
Message-ID: <1617711734.82.0.851064276146.issue43747@roundup.psfhosted.org>


New submission from Kun He <hekun19890913 at gmail.com>:

Hello,

I'm working a C extension interface of Python. I want to create a new interpreter by using the function Py_NewInterpreter() in a new thread, which is created by pthread_create (my test files are in attachment), but there are always errors when calling Py_NewInterpreter() such as "failed: object already tracked by the garbage collector". 

I suppose that it may be a bug of Python source code? I would like to ask how to solve the problem and create a new interpreter in multi thread in Python C extension?

Sincerely,
Kun

----------
components: C API
files: newinter.tar.xz
messages: 390322
nosy: hekun19890913
priority: normal
severity: normal
status: open
title: Can't create new interpreter in multi thread
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49936/newinter.tar.xz

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

From report at bugs.python.org  Tue Apr  6 08:24:08 2021
From: report at bugs.python.org (Andre Roberge)
Date: Tue, 06 Apr 2021 12:24:08 +0000
Subject: [New-bugs-announce] [issue43748] Inconsistent grammar in new error
 message (introduced in 3.10.0a7)
Message-ID: <1617711848.38.0.240112674154.issue43748@roundup.psfhosted.org>


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

Python version 3.10.0a7 added a more informative error message for:

>>> f"{**k}"
  File "<stdin>", line 1
    (**k)
     ^
SyntaxError: f-string: can't use double starred expression here

Previously, the message was simply "SyntaxError: invalid syntax".  So, this change is certainly a welcome addition.

However, as far as I can tell, starting with Python 3.8, all previous uses of "can't" in error messages were replaced by "cannot".  Although it is an extremely minor point, it might be preferable for consistency to replace "can't" by "cannot" in this new error message.

----------
components: Interpreter Core
messages: 390323
nosy: aroberge
priority: normal
severity: normal
status: open
title: Inconsistent grammar in new error message (introduced in 3.10.0a7)
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 09:27:05 2021
From: report at bugs.python.org (Ian Norton)
Date: Tue, 06 Apr 2021 13:27:05 +0000
Subject: [New-bugs-announce] [issue43749] venv module does not copy the
 correct python exe
Message-ID: <1617715625.46.0.74507922397.issue43749@roundup.psfhosted.org>


New submission from Ian Norton <inorton at gmail.com>:

On windows, the venv module does not copy the correct python exe if the current running exe (eg sys.executable) has been renamed (eg, named python3.exe)

venv will only make copies of python.exe, pythonw.exe, python_d.exe or pythonw_d.exe.

If for example the python executable has been renamed from python.exe to python3.exe (eg, to co-exist in a system where multiple pythons are on PATH) then this can fail with errors like:

Error: [WinError 2] The system cannot find the file specified

When venv tries to run pip in the new environment.

If the running python executable is a differently named copy then errors like the one described in https://bugs.python.org/issue40588 are seen.

----------
components: Library (Lib)
messages: 390329
nosy: Ian Norton
priority: normal
severity: normal
status: open
title: venv module does not copy the correct python exe
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr  6 11:21:46 2021
From: report at bugs.python.org (Tom Cook)
Date: Tue, 06 Apr 2021 15:21:46 +0000
Subject: [New-bugs-announce] [issue43750] Undefined constant
 PACKET_MULTIHOST referred to in package socket
Message-ID: <1617722506.16.0.590696167901.issue43750@roundup.psfhosted.org>


New submission from Tom Cook <tom.k.cook at gmail.com>:

The documentation for the `AF_PACKET` address family refers to `PACKET_MULTIHOST`.  I believe this should read `PACKET_MULTICAST`, which is defined on Linux systems (`PACKET_MULTIHOST` is not).

----------
assignee: docs at python
components: Documentation
messages: 390345
nosy: Tom Cook, docs at python
priority: normal
severity: normal
status: open
title: Undefined constant PACKET_MULTIHOST referred to in package socket
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr  6 12:00:14 2021
From: report at bugs.python.org (PEW's Corner)
Date: Tue, 06 Apr 2021 16:00:14 +0000
Subject: [New-bugs-announce] [issue43751] await anext() returns None when
 default is given
Message-ID: <1617724814.14.0.517501509303.issue43751@roundup.psfhosted.org>


New submission from PEW's Corner <pewscorner at gmail.com>:

The new anext() builtin in Python 3.10.0a7 doesn't seem to work properly when a default value is provided as the second argument. Here's an example:

import asyncio

async def f():
    yield 'A'
    yield 'B'

async def main():
    g = f()
    print(await anext(g, 'Z'))  # Prints 'None' instead of 'A'!!!
    print(await anext(g, 'Z'))  # Prints 'None' instead of 'B'!!!
    print(await anext(g, 'Z'))  # Prints 'Z'
    g = f()
    print(await anext(g))       # Prints 'A'
    print(await anext(g))       # Prints 'B'
    print(await anext(g))       # Raises StopAsyncIteration

asyncio.run(main())

As indicated above, anext() works fine when no default is given (in the second half of main()), but produces None in every iteration when a default is given (in the first half of main()) except when the iterator is exhausted.

----------
components: Interpreter Core, asyncio
messages: 390349
nosy: asvetlov, pewscorner, yselivanov
priority: normal
severity: normal
status: open
title: await anext() returns None when default is given
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 14:29:34 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Tue, 06 Apr 2021 18:29:34 +0000
Subject: [New-bugs-announce] [issue43752] Fetching an empty value from date
 column crashes on SQLite.
Message-ID: <1617733774.24.0.888180861121.issue43752@roundup.psfhosted.org>


New submission from Mariusz Felisiak <felisiak.mariusz at gmail.com>:

We noticed a regression in Python3.10.0a7 (it works properly in Python3.10.0a6) when running Django's test suite. `convert_date()`[1] is called and crashes when fetching an empty value from `date` column on SQLite:

File "python3.10/lib/sqlite3/dbapi2.py", line 64, in convert_date
    return datetime.date(*map(int, val.split(b"-")))
ValueError: invalid literal for int() with base 10: b''

I will bisect a regression and submit PR.

[1] https://github.com/python/cpython/blob/50616223d1043f0f83534ffec38709439b8a49ab/Lib/sqlite3/dbapi2.py#L63-L64

----------
components: Library (Lib)
messages: 390357
nosy: berker.peksag, erlendaasland, felixxm
priority: normal
severity: normal
status: open
title: Fetching an empty value from date column crashes on SQLite.
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 14:38:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Apr 2021 18:38:58 +0000
Subject: [New-bugs-announce] [issue43753] [C API] Add Py_IS(x, y) macro
Message-ID: <1617734338.35.0.565380301548.issue43753@roundup.psfhosted.org>


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

I propose to add at least Py_Is(x, y) function to the Python C API which would be simply implemented as:

    static inline int Py_Is(PyObject *x, PyObject *y) { return (x == y); }

Right now, there is no benefit for CPython. The idea is to prepare the CPython code base for future optimization, like tagged pointers. It may help PyPy. It can also help to prepare C extensions to migrate to HPy, since HPy requires to use HPy_Is(ctx, x, y): "x == y" (where x and y types is HPy) fails with a compiler error with HPy.

--

CPython uses reference counting and singletons like None and False. The "x is y" operator in Python is implemented with the IS_OP opcode implemented in Python/ceval.c as:

        case TARGET(IS_OP): {
            PyObject *right = POP();
            PyObject *left = TOP();
            int res = (left == right)^oparg;
            PyObject *b = res ? Py_True : Py_False;
            Py_INCREF(b);
            SET_TOP(b);
            Py_DECREF(left);
            Py_DECREF(right);
            PREDICT(POP_JUMP_IF_FALSE);
            PREDICT(POP_JUMP_IF_TRUE);
            DISPATCH();
        }

In short, "x is y" in Python simply compares directly PyObject* pointer values in C: "x == y" where x and y are PyObject* pointers.

PyPy doesn't use reference counting and so implements "x is y" differently: id(x) == id(y) if I understood correctly. In PyPy, id(obj) is more complex than simply getting the object memory address. For example, id(1) is always 17 in PyPy (on Linux/x86-64 at least).

At the C API level, using "x == y" to check if y object "is" x object doesn't work well with PyPy object models. Moreover, "x == Py_None" doesn't work if None is stored as a tagged pointer in CPython.

--

Maybe we can also add functions to check if an object is a singleton:

* Py_IsNone(x): x == Py_None
* Py_IsTrue(x): x == Py_True
* Py_IsFalse(x): x == Py_False

See also bpo-39511 "[subinterpreters] Per-interpreter singletons (None, True, False, etc.)" which may need to replace Py_None singleton with Py_GetNone(). IMO it makes more sense to call Py_IS_NONE(x) function to express that code is run, rather than writing "x == Py_None" as if Py_None is and will always be a variable directly accesssible.

Py_IS_TRUE() name sounds like PyObject_IsTrue(). Can it be an issue? Can someone come with a better name?

----------
components: C API
messages: 390358
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Add Py_IS(x, y) macro
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 16:00:31 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 06 Apr 2021 20:00:31 +0000
Subject: [New-bugs-announce] [issue43754] Eliminate bindings for partial
 pattern matches
Message-ID: <1617739231.38.0.2365910918.issue43754@roundup.psfhosted.org>


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

This draft PR contains a couple of pattern matching improvements I'm experimenting with. Most significantly, it implements behavior that several people requested during the PEP 634 feedback process: no more name bindings for partial matches.

(One caveat: all names are bound *before* evaluating the corresponding guard. If the guard fails, these bindings won't be rolled back before matching the next case.)

In short, this is accomplished by storing captured objects on the stack underneath the more immediately important stuff, popping them all on failure or storing them all only once the *entire* pattern for that case matches. The control flow needs to be greatly simplified in order to make this work correctly, so the patch replaces the current "push bools and jump if false a bunch of times" flow with something much more efficient: jumping straight into a run of POP_TOPs on failure. We already do something very similar to this in pattern_helper_sequence_unpack (the comments in the current code explain it well).

Parts of the new code are a bit more complex than before (especially or-patterns, which need to do a bit of juggling on the stack to reorder captured items and avoid popping important data on failure), and other parts can certainly still be improved... but I personally consider it a win to have more intuitive partial match behavior with no performance penalty.

I thought I'd loop a few of you in on it to hear your thoughts before progressing much further.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 390368
nosy: Mark.Shannon, brandtbucher, gvanrossum, pablogsal
priority: normal
severity: normal
status: open
title: Eliminate bindings for partial pattern matches
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr  6 16:07:25 2021
From: report at bugs.python.org (Saiyang Gou)
Date: Tue, 06 Apr 2021 20:07:25 +0000
Subject: [New-bugs-announce] [issue43755] lambda expression no longer valid
 at comp_if in Python 3.9
Message-ID: <1617739645.22.0.813638332511.issue43755@roundup.psfhosted.org>


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

According to the documentation, a lambda expression at the `comp_if` position of a comprehension is allowed (can be parsed as `lambda_expr_nocond`). But this seems broken in Python 3.9 PEG parser. Example:

user at host:/$ python3.8
Python 3.8.9 (default, Apr  3 2021, 01:00:00)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> [x for x in range(10) if lambda: 1]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>
user at host:/$ python3.9
Python 3.9.3 (default, Apr  3 2021, 00:51:37)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> [x for x in range(10) if lambda: 1]
  File "<stdin>", line 1
    [x for x in range(10) if lambda: 1]
                             ^
SyntaxError: invalid syntax

----------
messages: 390369
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: lambda expression no longer valid at comp_if in Python 3.9
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Apr  6 19:04:31 2021
From: report at bugs.python.org (Saiyang Gou)
Date: Tue, 06 Apr 2021 23:04:31 +0000
Subject: [New-bugs-announce] [issue43756] About updating audit events when
 function gains new arguments
Message-ID: <1617750271.94.0.577978285316.issue43756@roundup.psfhosted.org>


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

I'm not sure what to do when a function already being audited gains new arguments which are also worth auditing. For example, issue 38144 brings new `root_dir` and `dir_fd` arguments to `glob.glob`. Currently `glob.glob` is already audited, with `(pathname, recursive)` as the event schema. However, the new `root_dir` and `dir_fd` arguments are important context for the glob operation and is also worth collecting into the event (as a comparison, `os.*` audit events already include `dir_fd`). The problem is how to incorporate the new arguments.

- Solution 1: Add new arguments to the existing event schema (on feature releases). In this ways, hooks expecting an arg tuple of the original length will be broken. Hooks taking arguments by subscripts (e.g. `pathname = args[0]`) may still work if we only append new arguments to the end of the event schema and never insert arguments in the middle.
- Solution 2: Add a new audit event. In this `glob` case, we add a new event which might be called `glob.glob.v2` or `glob.glob.3_10` or some other way. This will make sure the event schema is always fixed across different feature releases. But hooks may need to correctly handle all "versions" of events (e.g. do some thing like `if event.startswith('glob.glob')` instead of `if event == 'glob.glob'`).

I guess more audited functions may gain new arguments in the future so this problem is unavoidable. I would like some suggestions from Steve. Thanks!

----------
messages: 390386
nosy: gousaiyang, steve.dower
priority: normal
severity: normal
status: open
title: About updating audit events when function gains new arguments

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

From report at bugs.python.org  Tue Apr  6 22:32:48 2021
From: report at bugs.python.org (Barney Gale)
Date: Wed, 07 Apr 2021 02:32:48 +0000
Subject: [New-bugs-announce] [issue43757] pathlib: move 'resolve()' logic
 out of path flavour
Message-ID: <1617762768.57.0.0406169855145.issue43757@roundup.psfhosted.org>


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

Under-the-hood functionality in pathlib is divided between:

- The 'flavour', which implements path syntax (separators, casefolding, etc)
- The 'accessor', which accesses the local (file)system.

The '_WindowsFlavour/_PosixFlavour.resolve()' function is misplaced, as it requires OS calls such as `os.getcwd()`, `os.readlink()`, and `nt._getfinalpathname()`. While the implementation *does* differ across Windows and POSIX, it's still properly part of the accessor interface, and not the flavour interface.

In preparation for addressing bpo-24132 I'd like to get these interfaces really tidy. Once bpo-39899 is fixed, this will be the last remaining flavour method that does accessor-y things.

----------
components: Library (Lib)
messages: 390397
nosy: barneygale
priority: normal
severity: normal
status: open
title: pathlib: move 'resolve()' logic out of path flavour
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 01:05:52 2021
From: report at bugs.python.org (Justin Lee)
Date: Wed, 07 Apr 2021 05:05:52 +0000
Subject: [New-bugs-announce] [issue43758] dict.config
 TimedRotatingFileHandler filename .suffix does not function
Message-ID: <1617771952.69.0.757936133435.issue43758@roundup.psfhosted.org>


New submission from Justin Lee <tea940314 at gmail.com>:

Hi,

I would like to change the .suffix for the TimedRotatingFileHandler for the "future-created" file in dictConfig written in json.

Is there any suggestion on how to do that?

----------
messages: 390400
nosy: tea940314
priority: normal
severity: normal
status: open
title: dict.config TimedRotatingFileHandler filename .suffix does not function
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  7 04:07:48 2021
From: report at bugs.python.org (Nguyen Thai Binh)
Date: Wed, 07 Apr 2021 08:07:48 +0000
Subject: [New-bugs-announce] [issue43759] StreamHandler does not print to
 sys.stderr immediately
Message-ID: <1617782868.14.0.363269444057.issue43759@roundup.psfhosted.org>


New submission from Nguyen Thai Binh <binhnt.mdev at gmail.com>:

When logger.exception() is called in a `catch` clause, it never logs to sys.stderr immediately. Sometimes it only outputs when the program almost finishes. I don't know how to reproduce as it is occasional. Attached is the logging configuration for my program.

Thank you.

----------
components: Library (Lib)
files: logger.py
messages: 390404
nosy: MunchDev
priority: normal
severity: normal
status: open
title: StreamHandler does not print to sys.stderr immediately
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49937/logger.py

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

From report at bugs.python.org  Wed Apr  7 05:35:49 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 07 Apr 2021 09:35:49 +0000
Subject: [New-bugs-announce] [issue43760] The DISPATCH() macro is not as
 efficient as it could be.
Message-ID: <1617788149.78.0.581729826447.issue43760@roundup.psfhosted.org>


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

The DISPATCH() macro has two failings.

1. Its check for tracing involves too much pointer chaser.

2. The logic assumes that computed-gotos is the "fast path" which makes switch dispatch, and therefore Python on Windows unnecessarily slow.

----------
messages: 390410
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: The DISPATCH() macro is not as efficient as it could be.

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

From report at bugs.python.org  Wed Apr  7 06:40:27 2021
From: report at bugs.python.org (Adrian Freund)
Date: Wed, 07 Apr 2021 10:40:27 +0000
Subject: [New-bugs-announce] [issue43761] Documenting dataclass and
 namedtuple changes for structural pattern matching
Message-ID: <1617792027.47.0.961772614464.issue43761@roundup.psfhosted.org>


New submission from Adrian Freund <git at freundtech.com>:

PEP 634 structural pattern matching adds an auto-generated __match_args__ attribute to classes with the dataclass decorator and to namedtuples.

This change is currently not documented in the dataclass and namedtuple documentation, nor is it mentioned in PEP 557 Data Classes.


I would suggest adding mentions of this behaviour in those three places.

Additionally I think adding a new parameter to switch off generating __match_args__ to dataclass should be considered, as everything else generated by dataclass can be switched off using a parameter.

----------
assignee: docs at python
components: Documentation
messages: 390413
nosy: brandtbucher, docs at python, freundTech, gvanrossum
priority: normal
severity: normal
status: open
title: Documenting dataclass and namedtuple changes for structural pattern matching
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 06:51:19 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 07 Apr 2021 10:51:19 +0000
Subject: [New-bugs-announce] [issue43762] Add audit events for loading of
 sqlite3 extensions
Message-ID: <1617792679.62.0.407303342016.issue43762@roundup.psfhosted.org>


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

If Python is configured with --enable-loadable-sqlite-extensions, it is possible to load third party SQLite extensions (shared libraries/DLL?s) via the sqlite3 extension module. When enabled, the sqlite3.Connection.enable_load_extension() class method will enable the loading of third party extensions via SQL queries, using the SQL function load_extension(). It also enables loading extension via C, using the sqlite3.Connection.load_extension() class method.

Suggesting to add the following audit event names to respectively the sqlite3.Connection.enable_load_extension() and sqlite3.Connection.load_extension() methods:
- sqlite3.enable_load_extension
- sqlite3.load_extension

Ref.
- https://discuss.python.org/t/should-we-audit-enabling-loading-of-sqlite3-extensions-shared-libraries/8124
- https://www.sqlite.org/loadext.html
- https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.enable_load_extension

----------
components: Library (Lib)
messages: 390414
nosy: berker.peksag, christian.heimes, erlendaasland
priority: normal
severity: normal
status: open
title: Add audit events for loading of sqlite3 extensions
type: security
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 07:36:12 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 07 Apr 2021 11:36:12 +0000
Subject: [New-bugs-announce] [issue43763] [sqlite3] Use
 SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION iso. sqlite3_enable_load_extension()
Message-ID: <1617795372.37.0.944356546491.issue43763@roundup.psfhosted.org>


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

Quoting from the SQLite docs:
"It is recommended that extension loading be enabled using the SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION method rather than this interface, so the load_extension() SQL function remains disabled. This will prevent SQL injections from giving attackers access to extension loading capabilities."

Suggesting to make sqlite3.Connection.enable_load_extension a module level function, and use sqlite3_db_config() iso. sqlite3_enable_load_extension(). We could add an optional argument for also enabling the SQL function.

1. Introduce sqlite3.enable_load_extension(enable, /, enable_sql_api=False)
2. Add deprecation warning to sqlite3.Connection.enable_load_extension()
3. In Python 3.12, remove sqlite3.Connection.enable_load_extension()

----------
components: Extension Modules
messages: 390422
nosy: berker.peksag, christian.heimes, erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] Use SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION iso. sqlite3_enable_load_extension()
type: security
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 09:07:21 2021
From: report at bugs.python.org (Adrian Freund)
Date: Wed, 07 Apr 2021 13:07:21 +0000
Subject: [New-bugs-announce] [issue43764] Turning off generation of
 __match_args__ for dataclasses
Message-ID: <1617800841.7.0.162045441395.issue43764@roundup.psfhosted.org>


New submission from Adrian Freund <git at freundtech.com>:

The dataclass decorator can take multiple parameters to enable or disable the generation of certain methods.

PEP 634 Structural Pattern Matching extends dataclasses to also generate a __match_args__ attribute.

I think adding a parameter to enable and disable generation of __match_args__ should be to dataclass should also be considered for consistency.

Note that setting compare=False on a dataclass.field already excludes that field from __match_args__, but there is no way to disable generation of __match_args__ completely.

----------
components: Library (Lib)
messages: 390429
nosy: brandtbucher, eric.smith, freundTech, gvanrossum
priority: normal
severity: normal
status: open
title: Turning off generation of __match_args__ for dataclasses
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 09:48:01 2021
From: report at bugs.python.org (Christer Weinigel)
Date: Wed, 07 Apr 2021 13:48:01 +0000
Subject: [New-bugs-announce] [issue43765] Add support for the RFC5705
 SSL_export_keying_material function
Message-ID: <1617803281.61.0.449713524257.issue43765@roundup.psfhosted.org>


New submission from Christer Weinigel <christer at weinigel.se>:

OpenSSL has a function to "SSL_export_keying_material" as described in RFC5705.  This function is needed to be able to support a bunch of other protocols such as "Network Time Security for the Network Time Protocol" defined in  RFC8915 and half a dozen other RFCs.

I have written a patch to add support for this function which can be found on github:

https://github.com/wingel/cpython

And it is used in my implementation of the NTS procotol which can also be found on github:

https://github.com/Netnod/nts-poc-python

It would be very nice if mainline Python could support for this function in the future so that I don't have to maintain a patched version of Python for this.

I'll make a pull request on github for this when I have a bpo number.

----------
assignee: christian.heimes
components: SSL
messages: 390432
nosy: christian.heimes, wingel71
priority: normal
severity: normal
status: open
title: Add support for the RFC5705 SSL_export_keying_material function
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 10:27:50 2021
From: report at bugs.python.org (Ken Jin)
Date: Wed, 07 Apr 2021 14:27:50 +0000
Subject: [New-bugs-announce] [issue43766] Implement PEP 647 (User-Defined
 Type Guards) in typing.py
Message-ID: <1617805670.27.0.185154049077.issue43766@roundup.psfhosted.org>


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

PEP 647 was recently accepted by the SC:
https://mail.python.org/archives/list/python-dev at python.org/thread/2ME6F6YUVKHOQYKSHTVQQU5WD4CVAZU4/

I'd like to work on the implementation for typing.py and any required docs later on (unless someone is already working on it, then I hope you'd let me help too ;). Hopefully I can get it in before the 3.10 beta freeze.

typing_extensions will need a port too, though that is much less urgent at the moment.

----------
components: Library (Lib)
messages: 390436
nosy: gvanrossum, kj
priority: normal
severity: normal
status: open
title: Implement PEP 647 (User-Defined Type Guards) in typing.py
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 14:33:30 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 07 Apr 2021 18:33:30 +0000
Subject: [New-bugs-announce] [issue43767] Compiler arning about 'Yield'
 macro redefinition on Windows
Message-ID: <1617820410.09.0.691386987943.issue43767@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

When building from scratch on Windows I get this warning:

c:\program files (x86)\windows kits\10\include\10.0.17763.0\um\winbase.h(103): warning C4005: 'Yield': macro redefinition [C:\Users\gvanrossum\cpython\PCbuild\pythoncore.vcxproj]

I know there is at least one place where we try to prevent this warning, e.g. in Include/internal/pycore_ast.h there's this line:

#undef Yield   /* undefine macro conflicting with <winbase.h> */

But apparently this isn't enough, or the error comes from a different file, or some rearrangement of header files made this #undef ineffective.

Victor, is it possible that your https://github.com/python/cpython/pull/24933 reintroduced this warning?

Steve, what can I do to diagnose this better? (The warning doesn't tell me where winbase.h was included.)

----------
components: Windows
messages: 390462
nosy: gvanrossum, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Compiler arning about 'Yield' macro redefinition on Windows
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr  7 15:12:33 2021
From: report at bugs.python.org (Jerry Chen)
Date: Wed, 07 Apr 2021 19:12:33 +0000
Subject: [New-bugs-announce] [issue43768] Possible race condition on
 multiprocessing.Manager().dict() on macOS
Message-ID: <1617822753.2.0.370273367232.issue43768@roundup.psfhosted.org>


New submission from Jerry Chen <jerryc443 at gmail.com>:

I am not sure if this is a bug or an expected case.

Long story short, I tried to print the content of a `multiprocessing.Manager().dict()` in the main thread, but I got a strange error.

I encountered this error only when the number of pools is rather large (>20) and only on `macOS` (works perfectly on `Linux`).

Specs:
```
  CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
macOS: 11.2.3
```

The minimum err code is attached:
```python3
#!/usr/bin/env python3

from contextlib import suppress
import multiprocessing as mp
import time


def run():
    D[mp.current_process().name] = 'some val'
    time.sleep(0.5)


if __name__ == '__main__':
    mp.set_start_method('fork')
    D, rets = mp.Manager().dict(), []
    with mp.Pool(25) as p:
        for _ in range(33):
            rets.append(p.apply_async(run))
        while rets:
            for ret in rets[:]:
                with suppress(mp.TimeoutError):
                    ret.get(timeout=0)
                    rets.remove(ret)
                    print(len(D))

```

Error: 
```
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py", line 801, in _callmethod
    conn = self._tls.connection
AttributeError: 'ForkAwareLocal' object has no attribute 'connection'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/Users/???", line 9, in run
    D[mp.current_process().name] = 'some val'
  File "<string>", line 2, in __setitem__
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py", line 805, in _callmethod
    self._connect()
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py", line 792, in _connect
    conn = self._Client(self._token.address, authkey=self._authkey)
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py", line 507, in Client
    c = SocketClient(address)
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py", line 635, in SocketClient
    s.connect(address)
ConnectionRefusedError: [Errno 61] Connection refused
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/???", line 22, in <module>
    ret.get(timeout=0)
  File "/usr/local/Cellar/python at 3.9/3.9.2_4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/pool.py", line 771, in get
    raise self._value
ConnectionRefusedError: [Errno 61] Connection refused
```

----------
components: macOS
messages: 390468
nosy: jerryc443, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Possible race condition on multiprocessing.Manager().dict() on macOS
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  7 17:24:15 2021
From: report at bugs.python.org (Philip Bond)
Date: Wed, 07 Apr 2021 21:24:15 +0000
Subject: [New-bugs-announce] [issue43769] ipaddress module takes bytes input
 as valid ip address
Message-ID: <1617830655.85.0.0538438287047.issue43769@roundup.psfhosted.org>


New submission from Philip Bond <philip.bond at fasthosts.com>:

Hi I came across an issue with the ipaddress module where it doesent raise a ValueError when passed a non IP address.

Example see attached file  use tabs for indents and that doesent work with the form.

What happens is it when it takes b'PING' as the call to ipaddress.IPv4Address(address) as the byte value == 4 it doesent raise a ValueError as the bytes for PING are 50 49 4e 47

----------
components: Unicode
files: cidr-gen.py
messages: 390478
nosy: ezio.melotti, philip.bond, vstinner
priority: normal
severity: normal
status: open
title: ipaddress module takes bytes input as valid ip address
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49940/cidr-gen.py

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

From report at bugs.python.org  Wed Apr  7 17:48:22 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Apr 2021 21:48:22 +0000
Subject: [New-bugs-announce] [issue43770] Rework C types initialization
Message-ID: <1617832102.18.0.477515294136.issue43770@roundup.psfhosted.org>


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

Currently, PyType_Ready() is called late on many static types, which can lead to bugs. For example, PyObject_SetAttr() can fail if the type of the object is not ready yet. PyType_Read() is responsible to initialize tp_getattro and tp_setattro members of the PyTypeObject structure.

We must explicitly initialize all static types before using them.

Moreover, many static types initialize explicitly :

  tp_getattro = PyObject_GenericGetAttr

and:

  tp_setattro = PyObject_GenericSetAttr

whereas it's the default implementation. They can be omitted.

I created this issue as a placeholder for multiple changes to modify how types implemented in C are initialized.

----------
components: Interpreter Core
messages: 390484
nosy: vstinner
priority: normal
severity: normal
status: open
title: Rework C types initialization
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  8 05:33:51 2021
From: report at bugs.python.org (Andrey Moiseev)
Date: Thu, 08 Apr 2021 09:33:51 +0000
Subject: [New-bugs-announce] [issue43771] [Windows] stdin line buffer size
Message-ID: <1617874431.78.0.824806811531.issue43771@roundup.psfhosted.org>


New submission from Andrey Moiseev <o2g.org.ru at gmail.com>:

sys.stdin.readline() in Windows console only allows 512 characters on input per line. So large pastes are truncated at 512 chars, which is a bit inconvenient for prototyping.

The buffer size seems to be determined by BUFSIZ compile time constant:
https://github.com/python/cpython/blob/63298930fb531ba2bb4f23bc3b915dbf1e17e9e1/Modules/_io/winconsoleio.c#L30-L31

In C, I am able to set a larger buffer at runtime with setvbuf() call:
setvbuf(stdin, NULL, 0, 2024);

But I can't seem to make it work through ctypes.cdll.msvcrt.setvbuf

----------
components: Windows
messages: 390518
nosy: Andrey Moiseev, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] stdin line buffer size
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  8 07:09:29 2021
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 08 Apr 2021 11:09:29 +0000
Subject: [New-bugs-announce] [issue43772] Minor repr error in
 typing.TypeVar.__ror__()
Message-ID: <1617880169.66.0.0347480943951.issue43772@roundup.psfhosted.org>


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

The implementation of the | operator for TypeVar objects is as follows:

    def __or__(self, right):
        return Union[self, right]

    def __ror__(self, right):
        return Union[self, right]

I think the implementation of __ror__ is ever-so-slightly inaccurate.  Shouldn't it be this?

    def __ror__(self, left):
        return Union[left, self]

I assume this wouldn't affect runtime behavior, as unions are sets and are presumably unordered.  The only observable difference should be in the repr() (and only then if both are non-None), as this reverses the elements.  The repr for Union does preserve the order of the elements it contains, so it's visible to the user there.

----------
components: Library (Lib)
messages: 390524
nosy: larry
priority: low
severity: normal
stage: test needed
status: open
title: Minor repr error in typing.TypeVar.__ror__()
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  8 09:31:56 2021
From: report at bugs.python.org (Carlton Gibson)
Date: Thu, 08 Apr 2021 13:31:56 +0000
Subject: [New-bugs-announce] [issue43773] macOS official installer builds
 not respecting DYLD_LIBRARY_PATH environment variable.
Message-ID: <1617888716.6.0.448516461166.issue43773@roundup.psfhosted.org>


New submission from Carlton Gibson <carlton.gibson at noumenal.es>:

Hi. 

On MacOS 11.3 "Big Sur", with the latest 3.9.4 installed with the official installer downloaded from python.org, the DYLD_LIBRARY_PATH environment variable is not being respected. 

This looks very similar to Issue40198
https://bugs.python.org/issue40198

To begin everything looks correct as per 40198:

    ~ $ python3 --version
    Python 3.9.4
    ~ $ which python3
    /Library/Frameworks/Python.framework/Versions/3.9/bin/python3
    ~ $ codesign --display --entitlements=:- /Library/Frameworks/Python.framework/Versions/3.9/bin/python3
    Executable=/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.automation.apple-events</key>
    <true/>
    </dict>
    </plist>


The active python is that from the official installer, and it looks to have the correct entitlements, as per the resolution to 40198. 

However, it's not working in practice. 

I create a script test: 

    ~ $ cat ~/bin/sqlite_config.py 
    import os
    import sqlite3

    print("DYLD_LIBRARY_PATH:" )
    print(os.getenv('DYLD_LIBRARY_PATH'))

    print("SQLite Version:")
    print(sqlite3.sqlite_version)

Together with a compiled SQLite version: 

    ~ $ ls /Users/carlton/lib/sqlite/3.35.4
    libsqlite3.dylib

Trying to use this, the dylib is not picked up: 

    ~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" python3 ~/bin/sqlite_config.py 
    DYLD_LIBRARY_PATH:
    /Users/carlton/lib/sqlite/3.35.4
    SQLite Version:
    3.34.0

Contrast the same when run with a pyenv installed python: 

    ~ $ pyenv which python3.8
    /Users/carlton/.pyenv/versions/3.8.3/bin/python3.8
    ~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" /Users/carlton/.pyenv/versions/3.8.3/bin/python3.8 ~/bin/sqlite_config.py 
    DYLD_LIBRARY_PATH:
    /Users/carlton/lib/sqlite/3.35.4
    SQLite Version:
    3.35.4

The expected result, in both cases, is that the last lines should read: 

    SQLite Version:
    3.35.4



I don't know if this is the result of a tightening in macOS' SIP in Big Sur (or something else entirely...) ??I thought to test it by installing the official build in a different location (so not in the SIP protected `/Library/` space but somewhere in `~` but the installer doesn't look like it allows that (no doubt for good reasons). 

Next step for me with be building from source to see if I can dig deeper, but I thought I'd report it, as it does look like a change in behaviour from the *success* reported in 40198. 

Thanks very much!

----------
components: macOS
messages: 390529
nosy: carltongibson, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  8 12:18:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Apr 2021 16:18:07 +0000
Subject: [New-bugs-announce] [issue43774] [Doc] Document configure options
 in the Python documentation
Message-ID: <1617898687.07.0.687741116683.issue43774@roundup.psfhosted.org>


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

Attached PR documents configure, compiler and linker options to build Python.

----------
assignee: docs at python
components: Documentation
messages: 390536
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: [Doc] Document configure options in the Python documentation
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  8 13:56:34 2021
From: report at bugs.python.org (Maria Kazakova)
Date: Thu, 08 Apr 2021 17:56:34 +0000
Subject: [New-bugs-announce] [issue43775] JSON Parsing Alarm: Requests +
 Json = JSONDecodeError
Message-ID: <1617904594.75.0.587910269593.issue43775@roundup.psfhosted.org>


New submission from Maria Kazakova <marikasakowa at gmail.com>:

I tried to use the usual code:
response = requests.get (url)
response.json () OR json.loads (response.text)
BUT
it returns JSONDecodeError Expecting value: line 1 column 1 (char 0) ? no matter, which website I am trying to parse, with headers or without them. 
However, response.status_code = 200 and response.text returns the whole html-content. Two days ago everything worked completely fine, and now this disaster happens. I asked a couple of friends to try the same ? and everyone failed to succeed, everyone gets this error ? using Jupyter Notebook (+Anaconda, Python 3.7), PyCharm (+Python 3.9) and Google Colab.
Please help :(

----------
components: Windows
messages: 390539
nosy: marikasakowa, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: JSON Parsing Alarm: Requests + Json = JSONDecodeError
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Thu Apr  8 14:42:23 2021
From: report at bugs.python.org (mkocher)
Date: Thu, 08 Apr 2021 18:42:23 +0000
Subject: [New-bugs-announce] [issue43776] Popen with shell=True yield
 mangled repr output
Message-ID: <1617907343.84.0.247878991461.issue43776@roundup.psfhosted.org>


New submission from mkocher <Michael.Kocher at me.com>:

When using Popen with shell=True, the output of the repr is not particularly user friendly. 

When using the form `p = Popen('python --version'.split())`, the output is reasonably output in a user friendly form of `<Popen: returncode: None args: ['python', '--version']>`. 

However, when running with `shell=True`, the output is mangled.

For example, trying to run `python --help` via `p = Popen('python --version', shell=True)` yields the following output.

`<Popen: returncode: None args: ['p', 'y', 't', 'h', 'o', 'n', ' ', '-', '-',...>`

The original change appears to be motivated by https://bugs.python.org/issue38724 

and the PR here:

https://github.com/python/cpython/pull/17151/files

----------
components: Library (Lib)
messages: 390542
nosy: mkocher
priority: normal
severity: normal
status: open
title: Popen with shell=True yield mangled repr output
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  8 16:23:14 2021
From: report at bugs.python.org (Bob Kline)
Date: Thu, 08 Apr 2021 20:23:14 +0000
Subject: [New-bugs-announce] [issue43777] Remove description of "pip search"
 command from tutorial
Message-ID: <1617913394.59.0.105021549467.issue43777@roundup.psfhosted.org>


New submission from Bob Kline <bkline at rksystems.com>:

The official tutorial instructs users to find third-party packages by using the "pip search" command, which no longer works (and will be deprecated -- and presumably subsequently removed -- according to the error message). See https://docs.python.org/3.10/tutorial/venv.html#managing-packages-with-pip

That passage should be removed from the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 390550
nosy: bkline, docs at python
priority: normal
severity: normal
status: open
title: Remove description of "pip search" command from tutorial
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  8 16:31:24 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Apr 2021 20:31:24 +0000
Subject: [New-bugs-announce] [issue43778] [Doc]
 Doc/tools/extensions/glossary_search.py fails with FileNotFoundError if the
 _static/ directory doesn't exist
Message-ID: <1617913884.68.0.820989252764.issue43778@roundup.psfhosted.org>


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

Doc/tools/extensions/glossary_search.py failed multiple times on my doc PR:
https://github.com/python/cpython/pull/25283

The fail is not deterministic (random error, timing issue?), it depends if the directory was already created by something else or not.

Error on the Docs PR job of the Azure Pipeline:
--------------
2021-04-08T17:55:57.7774293Z writing output... [ 98%] whatsnew/3.5
2021-04-08T17:55:58.0531588Z writing output... [ 98%] whatsnew/3.6
2021-04-08T17:55:58.3085384Z writing output... [ 99%] whatsnew/3.7
2021-04-08T17:55:58.5638166Z writing output... [ 99%] whatsnew/3.8
2021-04-08T17:55:59.3385073Z writing output... [ 99%] whatsnew/3.9
2021-04-08T17:55:59.5205350Z writing output... [ 99%] whatsnew/changelog
2021-04-08T17:56:02.4282200Z writing output... [100%] whatsnew/index
2021-04-08T17:56:03.1454692Z 
2021-04-08T17:56:03.1463636Z Writing glossary.json
2021-04-08T17:56:03.1466614Z 
2021-04-08T17:56:03.1467473Z Exception occurred:
2021-04-08T17:56:03.3286028Z   File "/home/vsts/work/1/s/Doc/tools/extensions/glossary_search.py", line 49, in on_build_finish
2021-04-08T17:56:03.3287379Z     with open(path.join(app.outdir, '_static', 'glossary.json'), 'w') as f:
2021-04-08T17:56:03.3288351Z FileNotFoundError: [Errno 2] No such file or directory: '/home/vsts/work/1/s/Doc/build/html/_static/glossary.json'
2021-04-08T17:56:03.3294489Z The full traceback has been saved in /tmp/sphinx-err-1c8jemiu.log, if you want to report the issue to the developers.
2021-04-08T17:56:03.3295501Z Please also report this if it was a user error, so that a better error message can be provided next time.
2021-04-08T17:56:03.3296536Z A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
--------------
https://dev.azure.com/Python/cpython/_build/results?buildId=78035&view=results

Error on Travis CI:
--------------
PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees  -q -W -j4 -W . build/html 

Extension error:

Handler <function on_build_finish at 0x7f6ed4c6abf8> for event 'build-finished' threw an exception (exception: [Errno 2] No such file or directory: '/home/travis/build/python/cpython/Doc/build/html/_static/glossary.json')

Makefile:49: recipe for target 'build' failed
--------------
https://travis-ci.com/github/python/cpython/jobs/497108477


Attached PR fix the extension: create the directory if it doesn't exists.

----------
assignee: docs at python
components: Documentation
messages: 390552
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: [Doc] Doc/tools/extensions/glossary_search.py fails with FileNotFoundError if the _static/ directory doesn't exist
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  8 18:08:01 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 08 Apr 2021 22:08:01 +0000
Subject: [New-bugs-announce] [issue43779] Fix possible _PyArena_AddPyObject
 ref leaks
Message-ID: <1617919681.12.0.940558119091.issue43779@roundup.psfhosted.org>


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

_PyArena_AddPyObject() only steals the object reference if successful.

- In Parser/pegen.c, _PyPegen_fill_token(), the return value is not checked at all.
- In Parser/asdl_c.py, none of the (two) calls to _PyArena_AddPyObject() decref on failure
- Ditto for Python/Python-ast.c


Attached patch fixes all callers. I'll put up a PR if it looks ok.

Alternatively, one could make _PyArena_AddPyObject() _not_ steal the reference, but since it's an exposed API, that's probably not an option.

----------
files: patch.diff
keywords: patch
messages: 390559
nosy: erlendaasland, pablogsal
priority: normal
severity: normal
status: open
title: Fix possible _PyArena_AddPyObject ref leaks
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49943/patch.diff

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

From report at bugs.python.org  Thu Apr  8 19:51:56 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2021 23:51:56 +0000
Subject: [New-bugs-announce] [issue43780] Sync importlib_metadata
 enhancements through 3.10.
Message-ID: <1617925916.07.0.133652663909.issue43780@roundup.psfhosted.org>


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

Incorporate importlib_metadata changes from 3.8 through 3.10: https://importlib-metadata.readthedocs.io/en/latest/history.html#v3-10-0

Two main changes:

- Add mtime-based caching during distribution discovery.
- Flagged use of dict result from ``entry_points`` as deprecated.

----------
components: Library (Lib)
messages: 390572
nosy: jaraco
priority: normal
severity: normal
status: open
title: Sync importlib_metadata enhancements through 3.10.
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr  8 21:23:59 2021
From: report at bugs.python.org (Sam Stern)
Date: Fri, 09 Apr 2021 01:23:59 +0000
Subject: [New-bugs-announce] [issue43781] SIGSEGV when replacing
 _multiprocessing.SemLock at runtime
Message-ID: <1617931439.33.0.179250347978.issue43781@roundup.psfhosted.org>


New submission from Sam Stern <jstern at umass.edu>:

When patching `_multiprocessing.SemLock` at runtime and then instantiating an instance of `multiprocessing.Pool`, the interpreter throws a SIGSEGV when trying to access a field of `_multiprocessing.SemLock` on pre-3.9 pythons

----------
components: Interpreter Core
files: this-segfaults.py
messages: 390577
nosy: sternj
priority: normal
severity: normal
status: open
title: SIGSEGV when replacing _multiprocessing.SemLock at runtime
type: crash
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49945/this-segfaults.py

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

From report at bugs.python.org  Thu Apr  8 21:52:15 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 09 Apr 2021 01:52:15 +0000
Subject: [New-bugs-announce] [issue43782] Failure to build from source on
 ppc64le on ubuntu xenial
Message-ID: <1617933135.46.0.871973088731.issue43782@roundup.psfhosted.org>


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

I realize this is unlikely to be a helpful report, but something that changed between 3.9.3 and 3.9.4 has caused the build to break on (admittedly a strange platform) ppc64le


I attached the build log (zipped because otherwise it's too big ?)

The live URL is here: https://launchpadlibrarian.net/532585040/buildlog_ubuntu-xenial-ppc64el.python3.9_3.9.4-1+xenial1_BUILDING.txt.gz

Probably the most relevant part of the bug report is this bit, though I'm guessing so I don't really know what is useful and what is not.

```
Preprocessed source stored into /tmp/ccIkITd0.out file, please attach this to your bugreport.
=== BEGIN GCC DUMP ===
// Target: powerpc64le-linux-gnu
// Configured with: ../src/configure -v --with-pkgversion='Ubuntu/IBM 5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-ppc64el --with-arch-directory=ppc64le --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
// Thread model: posix
// gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.12) 
// 
// ../Python/ceval.c: In function 'is_tstate_valid':
// ../Python/ceval.c:5694:1: internal compiler error: Segmentation fault
//  }
//  ^
// Please submit a full bug report,
// with preprocessed source if appropriate.
// See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
```

----------
components: Build
files: buildlog.tgz
messages: 390580
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: Failure to build from source on ppc64le on ubuntu xenial
versions: Python 3.9
Added file: https://bugs.python.org/file49946/buildlog.tgz

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

From report at bugs.python.org  Thu Apr  8 22:06:06 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 09 Apr 2021 02:06:06 +0000
Subject: [New-bugs-announce] [issue43783] Make ParamSpec.args/kwargs more
 useful objects
Message-ID: <1617933966.5.0.0238313977797.issue43783@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

Currently, typing.ParamSpec.args and ParamSpec.kwargs are just object() instances, which makes them useless for runtime inspection of __annotations__. This type was introduced by PEP 612.

Instead, I propose to make them return some special helper object with __origin__ set to the underlying ParamSpec object. I'll work on a PR soon.

----------
components: Library (Lib)
messages: 390583
nosy: Jelle Zijlstra, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Make ParamSpec.args/kwargs more useful objects
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr  9 01:25:49 2021
From: report at bugs.python.org (Kevin M)
Date: Fri, 09 Apr 2021 05:25:49 +0000
Subject: [New-bugs-announce] [issue43784] [Windows] interpreter hangs
 indefinitely on subprocess.communicate during __del__ at script exit
Message-ID: <1617945949.93.0.237236734747.issue43784@roundup.psfhosted.org>


New submission from Kevin M <sylikc at gmail.com>:

I've noticed an issue (or user error) in which Python a call that otherwise usually works in the __del__ step of a class will freeze when the Python interpreter is exiting.

I've attached sample code that I've ran against Python 3.9.1 on Windows 10.

The code below runs a process and communicates via the pipe.

class SubprocTest(object):
	def run(self):
		print("run")
		proc_args = ["cmd.exe"]
		self._process = subprocess.Popen(proc_args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
	
	def __del__(self):
		print("__del__")
		if self._process is not None:
			self.terminate()
	
	def terminate(self):
		print("terminate")
		self._process.communicate(input=b"exit\n", timeout=1)
		print("kill")
		self._process.kill()
		self._process = None

if __name__ == "__main__":
	s = SubprocTest()
	s.run()
	del s
	print("s done")
	
	t = SubprocTest()
	t.run()
	print("t done")


Current output:
run
__del__
terminate
kill
s done
run
t done
__del__
terminate
<<<<<< hangs indefinitely here, even though timeout=1

Expected output:
run
__del__
terminate
kill
s done
run
t done
__del__
terminate
kill


In normal circumstances, when you del the object and force a run of __del__(), the process ends properly and the terminate() method completes.

When the Python interpreter exits, Python calls the __del__() method of the class.  In this case, the terminate() never completes and the script freezes indefinitely on the communicate()

----------
components: Library (Lib), Windows
files: win_subprocess_hang.py
messages: 390587
nosy: paul.moore, steve.dower, sylikc, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] interpreter hangs indefinitely on subprocess.communicate during __del__ at script exit
versions: Python 3.9
Added file: https://bugs.python.org/file49947/win_subprocess_hang.py

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

From report at bugs.python.org  Fri Apr  9 01:42:16 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 09 Apr 2021 05:42:16 +0000
Subject: [New-bugs-announce] [issue43785] bz2 performance issue.
Message-ID: <1617946936.07.0.338866506245.issue43785@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

The original issue is reported here.
https://discuss.python.org/t/non-optimal-bz2-reading-speed/6869

1. Only BZ2File uses RLock()

lzma and gzip don't use RLock(). It adds significant performance overhead.
When I removed `with self._lock:`, decompression speed improved from about 148k line/sec to 200k line/sec.


2. The default __iter__ calls `readline()` for each iteration.

BZ2File.readline() is implemented in C so it is slightly slow than C implementation.

If I add this `__iter__()` to BZ2File, decompression speed improved from about 148k lines/sec (or 200k lines/sec) to 500k lines/sec.

    def __iter__(self):
        self._check_can_read()
        return iter(self._buffer)

If this __iter__ method is safe, it can be added to gzip and lzma too.

----------
components: Library (Lib)
files: dec.py
messages: 390588
nosy: methane
priority: normal
severity: normal
status: open
title: bz2 performance issue.
versions: Python 3.10
Added file: https://bugs.python.org/file49948/dec.py

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

From report at bugs.python.org  Fri Apr  9 04:48:19 2021
From: report at bugs.python.org (=?utf-8?q?Nico_Schl=C3=B6mer?=)
Date: Fri, 09 Apr 2021 08:48:19 +0000
Subject: [New-bugs-announce] [issue43786] slice(None) is slice(None) is False
Message-ID: <1617958099.53.0.277889313543.issue43786@roundup.psfhosted.org>


New submission from Nico Schl?mer <nico.schloemer at gmail.com>:

I stumbled upon this when dealing with NumPy arrays:
```
slice(None) is slice(None)
```
```
False
```
This came up when trying to check if a variable `a` equals `slice(None)`. The comparison
```
a = slice(None)
a == slice(None)
```
```
True
```
works, but doesn't return a single Boolean if a is a NumPy array, for example.

Perhaps there's another way of finding out if a variable is exactly `slice(None)`, but the failure of `is` seems like a bug.

----------
messages: 390598
nosy: nschloe
priority: normal
severity: normal
status: open
title: slice(None) is slice(None) is False

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

From report at bugs.python.org  Fri Apr  9 04:49:43 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 09 Apr 2021 08:49:43 +0000
Subject: [New-bugs-announce] [issue43787] Optimize BZ2File, GzipFile,
 and LZMAFile __iter__ method.
Message-ID: <1617958183.01.0.290245206759.issue43787@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

__iter__ method of BZ2File, GzipFile, and LZMAFile is IOBase.__iter__. It calls `readline()` for each line.

Since `readline()` is defined as Python function, it is slower than C iterator. Adding custom __iter__ method that delegates to underlying buffer __iter__ makes `for line in file` 2x faster.

    def __iter__(self):
        self._check_can_read()
        return self._buffer.__iter__()

---

The original issue is reported here.
https://discuss.python.org/t/non-optimal-bz2-reading-speed/6869
This issue is relating to #43785.

----------
components: Library (Lib)
messages: 390599
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize BZ2File, GzipFile, and LZMAFile __iter__ method.
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr  9 06:04:48 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Apr 2021 10:04:48 +0000
Subject: [New-bugs-announce] [issue43788] Make ssl_data.h version specific
Message-ID: <1617962688.47.0.0760026042397.issue43788@roundup.psfhosted.org>


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

_ssl_data.h contains static tables with OpenSSL error names and reasons. The stables are created by scrapping header files. The current approach has two issues:

- error codes are version dependent. OpenSSL 1.1.1 uses different codes and has a different set of error reasons as 3.0.0.
- parsing header files with regular expressions is err-prone.

I'm going to introduce version-specific data tables and re-write the current make_ssl_data.py script to use OpenSSL's crypto/err/openssl.txt and crypto/err/openssl.ec. The text files exist since OpenSSL 1.1.

----------
assignee: christian.heimes
components: SSL
messages: 390603
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Make ssl_data.h version specific
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  9 08:06:06 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Apr 2021 12:06:06 +0000
Subject: [New-bugs-announce] [issue43789] OpenSSL 3.0.0: password callback
 called multiple times
Message-ID: <1617969966.42.0.0501200395584.issue43789@roundup.psfhosted.org>


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

OpenSSL 3.0.0 seems to invoke the password callback multiple times under some circumstances. This triggers a fatal error in Python when the first invocation sets an exception.

test_load_cert_chain (test.test_ssl.ContextTests) ... Fatal Python error: _PyEval_EvalFrameDefault: a function returned a result with an exception set
Python runtime state: initialized
ValueError: password cannot be longer than 1023 bytes

Current thread 0x00007fa88787f740 (most recent call first):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1395 in getpass_huge
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1415 in test_load_cert_chain
  File "/home/heimes/dev/python/cpython/Lib/unittest/case.py", line 549 in _callTestMethod
  File "/home/heimes/dev/python/cpython/Lib/unittest/case.py", line 592 in run
  File "/home/heimes/dev/python/cpython/Lib/unittest/case.py", line 652 in __call__
  File "/home/heimes/dev/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/heimes/dev/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/heimes/dev/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/heimes/dev/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/heimes/dev/python/cpython/Lib/unittest/runner.py", line 176 in run
  File "/home/heimes/dev/python/cpython/Lib/test/support/__init__.py", line 959 in _run_suite
  File "/home/heimes/dev/python/cpython/Lib/test/support/__init__.py", line 1082 in run_unittest
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 4836 in test_main
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/runtest.py", line 246 in _runtest_inner2
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/runtest.py", line 282 in _runtest_inner
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/runtest.py", line 194 in runtest
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/main.py", line 321 in rerun_failed_tests
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/main.py", line 698 in _main
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/main.py", line 641 in main
  File "/home/heimes/dev/python/cpython/Lib/test/libregrtest/main.py", line 719 in main
  File "/home/heimes/dev/python/cpython/Lib/test/__main__.py", line 2 in <module>
  File "/home/heimes/dev/python/cpython/Lib/runpy.py", line 86 in _run_code
  File "/home/heimes/dev/python/cpython/Lib/runpy.py", line 196 in _run_module_as_main

Extension modules: _testcapi (total: 1)


(gdb) bt
#0  0x00007ffff7c5d9d5 in raise () from /lib64/libc.so.6
#1  0x00007ffff7c468a4 in abort () from /lib64/libc.so.6
#2  0x000000000051bb53 in fatal_error_exit (status=<optimized out>) at Python/pylifecycle.c:2522
#3  0x000000000051f97e in fatal_error (fd=2, header=header at entry=1, prefix=prefix at entry=0x6c2f60 <__func__.47> "_PyEval_EvalFrameDefault", 
    msg=msg at entry=0x670aa8 "a function returned a result with an exception set", status=status at entry=-1) at Python/pylifecycle.c:2703
#4  0x000000000051f9df in _Py_FatalErrorFunc (func=func at entry=0x6c2f60 <__func__.47> "_PyEval_EvalFrameDefault", 
    msg=msg at entry=0x670aa8 "a function returned a result with an exception set") at Python/pylifecycle.c:2719
#5  0x00000000004d930c in _PyEval_EvalFrameDefault (tstate=0x807060, 
    f=Frame 0x7fffe950e5b0, for file /home/heimes/dev/python/cpython/Lib/test/test_ssl.py, line 1395, in getpass_huge (), throwflag=0) at Python/ceval.c:1733
#6  0x00000000004e640f in _PyEval_EvalFrame (throwflag=0, 
    f=Frame 0x7fffe950e5b0, for file /home/heimes/dev/python/cpython/Lib/test/test_ssl.py, line 1395, in getpass_huge (), tstate=0x807060)
    at ./Include/internal/pycore_ceval.h:46
#7  _PyEval_Vector (tstate=0x807060, con=0x7fffe9377c30, locals=locals at entry=0x0, args=<optimized out>, argcount=<optimized out>, kwnames=<optimized out>)
    at Python/ceval.c:5109
#8  0x000000000042bf08 in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:342
#9  0x00007fffe9cf502c in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=0, args=0x0, callable=<function at remote 0x7fffe9377c20>, tstate=0x807060)
    at ./Include/cpython/abstract.h:114
#10 _PyObject_CallNoArg (func=<function at remote 0x7fffe9377c20>) at ./Include/cpython/abstract.h:168
#11 _password_callback (buf=0x7fffffff80c0 "p", size=1023, rwflag=<optimized out>, userdata=0x7fffffff9820) at /home/heimes/dev/python/cpython/Modules/_ssl.c:3935
#12 0x00007fffe9a3bcd2 in ui_read (ui=0xc22d70, uis=0xba6190) at crypto/ui/ui_util.c:111
#13 0x00007fffe9a3a4e0 in UI_process (ui=0xc22d70) at crypto/ui/ui_lib.c:516
#14 0x00007fffe99a3d49 in do_ui_passphrase (pass=0x7fffffff87b0 "", pass_size=1024, pass_len=0x7fffffff8bb8, prompt_info=0x0, verify=0, ui_method=0xc20050, 
    ui_data=0x7fffffff9820) at crypto/passphrase.c:173
#15 0x00007fffe99a4143 in ossl_pw_get_passphrase (pass=0x7fffffff87b0 "", pass_size=1024, pass_len=0x7fffffff8bb8, params=0x0, verify=0, data=0xc21cc8)
    at crypto/passphrase.c:269
#16 0x00007fffe99a43ca in ossl_pw_passphrase_callback_dec (pass=0x7fffffff87b0 "", pass_size=1024, pass_len=0x7fffffff8bb8, params=0x0, arg=0xc21cc8)
    at crypto/passphrase.c:324
#17 0x00007fffe99a3f8a in ossl_pw_get_passphrase (pass=0x7fffffff87b0 "", pass_size=1024, pass_len=0x7fffffff8bb8, params=0x0, verify=0, data=0xc0d0c8)
    at crypto/passphrase.c:231
#18 0x00007fffe99a43ca in ossl_pw_passphrase_callback_dec (pass=0x7fffffff87b0 "", pass_size=1024, pass_len=0x7fffffff8bb8, params=0x0, arg=0xc0d0c8)
    at crypto/passphrase.c:324
#19 0x00007fffe9a9d5ca in der2key_decode_p8 (input_der=0x7fffffff8d50, input_der_len=1905, ctx=0xbb2c40, pw_cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, 
    pw_cbarg=0xc0d0c8, key_from_pkcs8=0x7fffe99e8653 <ossl_rsa_key_from_pkcs8>) at providers/implementations/encode_decode/decode_der2key.c:150
#20 0x00007fffe9a9e432 in rsa_d2i_PKCS8 (key=0x0, der=0x7fffffff8d50, der_len=1905, ctx=0xbb2c40, pw_cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, pw_cbarg=0xc0d0c8)
    at providers/implementations/encode_decode/decode_der2key.c:580
#21 0x00007fffe9a9da9d in der2key_decode (vctx=0xbb2c40, cin=0xc4d0d0, selection=135, data_cb=0x7fffe9931e91 <decoder_process>, data_cbarg=0x7fffffff8de0, 
    pw_cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, pw_cbarg=0xc0d0c8) at providers/implementations/encode_decode/decode_der2key.c:295
#22 0x00007fffe993240b in decoder_process (params=0x0, arg=0x7fffffff8f00) at crypto/encode_decode/decoder_lib.c:750
#23 0x00007fffe9930f03 in OSSL_DECODER_from_bio (ctx=0xc0d090, in=0xc09700) at crypto/encode_decode/decoder_lib.c:58
#24 0x00007fffe99310b6 in OSSL_DECODER_from_data (ctx=0xc0d090, pdata=0x7fffffff8fc0, pdata_len=0x7fffffff8fb8) at crypto/encode_decode/decoder_lib.c:108
#25 0x00007fffe9a2fc77 in try_key_value (data=0x7fffffff9060, ctx=0xc21c80, cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, cbarg=0xc21cc8, 
    libctx=0x7fffe9c1f880 <default_context_int>, propq=0x0) at crypto/store/store_result.c:288
#26 0x00007fffe9a301cc in try_key (data=0x7fffffff9060, v=0x7fffffff96c0, ctx=0xc21c80, provider=0x97f7d0, libctx=0x7fffe9c1f880 <default_context_int>, propq=0x0)
    at crypto/store/store_result.c:407
#27 0x00007fffe9a2f6e6 in ossl_store_handle_load_result (params=0x7fffffff92f0, arg=0x7fffffff96c0) at crypto/store/store_result.c:152
#28 0x00007fffe9ac4638 in file_load_construct (decoder_inst=0x88b0a0, params=0x7fffffff92f0, construct_data=0x7fffffff9640)
    at providers/implementations/storemgmt/file_store.c:402
#29 0x00007fffe9931fd6 in decoder_process (params=0x7fffffff92f0, arg=0x7fffffff94b0) at crypto/encode_decode/decoder_lib.c:566
#30 0x00007fffe9aa03a8 in pem2der_decode (vctx=0xbb6ef0, cin=0xc04d70, selection=0, data_cb=0x7fffe9931e91 <decoder_process>, data_cbarg=0x7fffffff94b0, 
    pw_cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, pw_cbarg=0xbc14f8) at providers/implementations/encode_decode/decode_pem2der.c:243
#31 0x00007fffe993240b in decoder_process (params=0x0, arg=0x7fffffff95d0) at crypto/encode_decode/decoder_lib.c:750
#32 0x00007fffe9930f03 in OSSL_DECODER_from_bio (ctx=0xbc14c0, in=0xc28ab0) at crypto/encode_decode/decoder_lib.c:58
#33 0x00007fffe9ac49db in file_load_file (ctx=0xc282b0, object_cb=0x7fffe9a2f3c2 <ossl_store_handle_load_result>, object_cbarg=0x7fffffff96c0, 
    pw_cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, pw_cbarg=0xc21cc8) at providers/implementations/storemgmt/file_store.c:522
--Type <RET> for more, q to quit, c to continue without paging--
#34 0x00007fffe9ac4f6f in file_load (loaderctx=0xc282b0, object_cb=0x7fffe9a2f3c2 <ossl_store_handle_load_result>, object_cbarg=0x7fffffff96c0, 
    pw_cb=0x7fffe99a4389 <ossl_pw_passphrase_callback_dec>, pw_cbarg=0xc21cc8) at providers/implementations/storemgmt/file_store.c:682
#35 0x00007fffe9a2c3ff in OSSL_STORE_load (ctx=0xc21c80) at crypto/store/store_lib.c:386
#36 0x00007fffe99c48d0 in pem_read_bio_key (bp=0xbb6050, x=0x0, cb=0x7fffe9cf4f99 <_password_callback>, u=0x7fffffff9820, libctx=0x0, propq=0x0, 
    expected_store_info_type=4, try_secure=1) at crypto/pem/pem_pkey.c:74
#37 0x00007fffe99c4b12 in PEM_read_bio_PrivateKey_ex (bp=0xbb6050, x=0x0, cb=0x7fffe9cf4f99 <_password_callback>, u=0x7fffffff9820, libctx=0x0, propq=0x0)
    at crypto/pem/pem_pkey.c:144
#38 0x00007fffe9c653e7 in SSL_CTX_use_PrivateKey_file (ctx=0xc28350, file=0x7fffea13a060 "/home/heimes/dev/python/cpython/Lib/test/keycert.passwd.pem", type=1)
    at ssl/ssl_rsa.c:372
#39 0x00007fffe9cf82ce in _ssl__SSLContext_load_cert_chain_impl (self=self at entry=0x7fffe94c9be0, certfile='/home/heimes/dev/python/cpython/Lib/test/keycert.passwd.pem', 
    keyfile=0x0, password=<optimized out>) at /home/heimes/dev/python/cpython/Modules/_ssl.c:4032

----------
assignee: christian.heimes
components: SSL
messages: 390608
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: OpenSSL 3.0.0: password callback called multiple times
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  9 08:47:49 2021
From: report at bugs.python.org (Bob Kline)
Date: Fri, 09 Apr 2021 12:47:49 +0000
Subject: [New-bugs-announce] [issue43790] CLA check fails with a 500 error
Message-ID: <1617972469.44.0.813759160932.issue43790@roundup.psfhosted.org>


New submission from Bob Kline <bkline at rksystems.com>:

The tool to check whether the CLA has been received fails with a 500 error.

Steps to reproduce:
1. Add your GitHub name to your b.p.o. record.
2. Navigate to https://check-python-cla.herokuapp.com/
3. Enter your GitHub name and press the "Check" button
4. "500 Internal server error / Server got itself in trouble"

----------
components: Demos and Tools
messages: 390612
nosy: bkline
priority: normal
severity: normal
status: open
title: CLA check fails with a 500 error

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

From report at bugs.python.org  Fri Apr  9 09:08:57 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Apr 2021 13:08:57 +0000
Subject: [New-bugs-announce] [issue43791] OpenSSL 3.0.0: TLS 1.0 / 1.1
 connections fail with TLSV1_ALERT_INTERNAL_ERROR
Message-ID: <1617973737.23.0.132771876709.issue43791@roundup.psfhosted.org>


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

With OpenSSL 3.0.0-alpha14 several tests for TLS 1.0 and 1.1 connections are failing handshake with "[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error". OpenSSL is configured with default security level "1". Tests are only passing with @SECLEVEL=0.

I think the security default callback refuses NID_sha1 and NID_sha1_md5 SSL_SECOP_SIGALG_SUPPORTED because their security bits are lower than minimum of 80 bits.

ssl_security_default_callback (s=0x7fffdc001840, ctx=0x0, op=327691, bits=67, nid=114, other=0x7fffe8ab194a, ex=0x0) at ssl/ssl_cert.c:969
ssl_security_default_callback (s=0x7fffdc001840, ctx=0x0, op=327691, bits=64, nid=64, other=0x7fffe8ab188a, ex=0x0) at ssl/ssl_cert.c:969


#0  tls_choose_sigalg (s=0x7fffdc001840, fatalerrs=1) at ssl/t1_lib.c:3307
#1  0x00007fffe9cb00f4 in tls_post_process_client_hello (s=0x7fffdc001840, wst=WORK_MORE_B) at ssl/statem/statem_srvr.c:2223
#2  0x00007fffe9cad560 in ossl_statem_server_post_process_message (s=0x7fffdc001840, wst=WORK_MORE_A) at ssl/statem/statem_srvr.c:1236
#3  0x00007fffe9c97e3d in read_state_machine (s=0x7fffdc001840) at ssl/statem/statem.c:670
#4  0x00007fffe9c97723 in state_machine (s=0x7fffdc001840, server=1) at ssl/statem/statem.c:442
#5  0x00007fffe9c971db in ossl_statem_accept (s=0x7fffdc001840) at ssl/statem/statem.c:270
#6  0x00007fffe9c5f5ac in SSL_do_handshake (s=0x7fffdc001840) at ssl/ssl_lib.c:3852

            if ((lu = tls1_get_legacy_sigalg(s, -1)) == NULL) {
                if (!fatalerrs)
                    return 1;
                SSLfatal(s, SSL_AD_INTERNAL_ERROR,
                         SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM);
                return 0;
            }

----------
assignee: christian.heimes
components: SSL
messages: 390618
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: OpenSSL 3.0.0: TLS 1.0 / 1.1 connections fail with TLSV1_ALERT_INTERNAL_ERROR
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  9 09:44:33 2021
From: report at bugs.python.org (Dmitry Marakasov)
Date: Fri, 09 Apr 2021 13:44:33 +0000
Subject: [New-bugs-announce] [issue43792] "bad argument to internal
 function" in cython
Message-ID: <1617975873.6.0.244911999729.issue43792@roundup.psfhosted.org>


New submission from Dmitry Marakasov <amdmi3 at amdmi3.ru>:

I'm playing with adding python3.10a7 port to FreeBSD ports collection, and have run into similar problem with building multiple third party modules (for instance, yaml, yarl and pystemmer). Here's log from yaml:

running build_ext
cythoning yaml/_yaml.pyx to yaml/_yaml.c
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "setup.py", line 271, in <module>
    setup(
  File "/usr/local/lib/python3.10/site-packages/setuptools/__init__.py", line 153, in setup
    return distutils.core.setup(**attrs)
  File "/usr/local/lib/python3.10/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.10/distutils/dist.py", line 966, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.10/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "setup.py", line 187, in run
    _build_ext.run(self)
  File "/usr/local/lib/python3.10/site-packages/Cython/Distutils/old_build_ext.py", line 186, in run
    _build_ext.build_ext.run(self)
  File "/usr/local/lib/python3.10/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "setup.py", line 229, in build_extensions
    ext.sources = self.cython_sources(ext.sources, ext)
  File "/usr/local/lib/python3.10/site-packages/Cython/Distutils/old_build_ext.py", line 346, in cython_sources
    result = cython_compile(source, options=options,
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 778, in compile
    return compile_single(source, options, full_module_name)
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 727, in compile_single
    return run_pipeline(source, options, full_module_name)
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 479, in run_pipeline
    context = options.create_context()
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 596, in create_context
    return Context(self.include_path, self.compiler_directives,
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 80, in __init__
    from . import Builtin, CythonScope
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/CythonScope.py", line 5, in <module>
    from .UtilityCode import CythonUtilityCode
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/UtilityCode.py", line 3, in <module>
    from .TreeFragment import parse_from_strings, StringParseContext
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/TreeFragment.py", line 17, in <module>
    from .Visitor import VisitorTransform
  File "Cython/Compiler/Visitor.py", line 17, in init Cython.Compiler.Visitor
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/ExprNodes.py", line 4742, in <module>
    class SliceIndexNode(ExprNode):
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/ExprNodes.py", line 4939, in SliceIndexNode
    get_slice_utility_code = TempitaUtilityCode.load(
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Code.py", line 404, in load
    return cls(**kwargs)
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Code.py", line 645, in __init__
    proto = sub_tempita(proto, context, file, name)
  File "/usr/local/lib/python3.10/site-packages/Cython/Compiler/Code.py", line 638, in sub_tempita
    return sub(s, **context)
  File "Cython/Tempita/_tempita.py", line 376, in Cython.Tempita._tempita.sub
  File "Cython/Tempita/_tempita.py", line 137, in Cython.Tempita._tempita.Template.__init__
  File "Cython/Tempita/_tempita.py", line 819, in Cython.Tempita._tempita.parse
  File "Cython/Tempita/_tempita.py", line 661, in Cython.Tempita._tempita.lex
SystemError: Python/getargs.c:2038: bad argument to internal function
*** Error code 1

----------
components: Extension Modules, FreeBSD
messages: 390621
nosy: AMDmi3, koobs
priority: normal
severity: normal
status: open
title: "bad argument to internal function" in cython
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr  9 09:55:22 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Apr 2021 13:55:22 +0000
Subject: [New-bugs-announce] [issue43793] [C API] Py_NewInterpreter() cannot
 be called from a thread which has no Python thread state
Message-ID: <1617976522.63.0.387381437279.issue43793@roundup.psfhosted.org>


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

Build attached newinter.c C extension. Example:

$ gcc -shared newinter.c $(pkg-config python-3.10 --cflags --libs) -o newinter.so -fPIC


Trying to load the C extension crashs in various ways. Crashes on a Python debug build:

(1)

$ PYTHONPATH=$PWD ./python -c 'import newinter'
create new thread
Modules/gcmodule.c:113: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small
Enable tracemalloc to get the memory block allocation traceback

object address  : 0x7f1a1163c8f0
object refcount : 1
object type     : 0x871020
object type name: dict
object repr     : {}

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: finalizing (tstate=0x0000000001e0d390)

Current thread 0x00007f1a115a0640 (most recent call first):
  File "<frozen importlib._bootstrap>", line 241 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 855 in exec_module
  File Exception ignored deletion of interned string failed"<frozen importlib._bootstrap>", line 688 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027 in _find_and_load
  File "<frozen importlib._bootstrap>", line 1207 in _install_external_importers
Segmentation fault (core dumped)

(2)

$ PYTHONPATH=$PWD ./python -c 'import newinter'
create new thread
Objects/unicodeobject.c:15769: _Py_NegativeRefcount: Assertion failed: object has negative ref count
Enable tracemalloc to get the memory block allocation traceback

object address  : 0x7fe124af08e0
object refcount : -1
object type     : 0x8797e0
object type name: str
object repr     : Debug memory block at address p=0x7fe124af08e0: API 'o'
    60 bytes originally requested
    The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
    The 8 pad bytes at tail=0x7fe124af091c are not all FORBIDDENBYTE (0xfd):
        at tail+0: 0x72 *** OUCH
        at tail+1: 0x5f *** OUCH
        at tail+2: 0x63 *** OUCH
        at tail+3: 0x61 *** OUCH
        at tail+4: 0x63 *** OUCH
        at tail+5: 0x68 *** OUCH
        at tail+6: 0x65 *** OUCH
        at tail+7: 0xfd
    Data at p: ff ff ff ff ff ff ff ff ... 61 6b 72 65 66 5f 5f 65<refcnt -1 at 0x7fe124af08e0>

Enable tracemalloc to get the memory block allocation traceback

Fatal Python error: _PyMem_DebugRawFree: bad trailing pad byte
Python runtime state: finalizing (tstate=0x0000000001564390)

Current thread 0x00007fe1321ff740 (most recent call first):
<no Python frame>

Extension modules: newinter (total: 1)
Aborted (core dumped)

(3)

$ PYTHONPATH=$PWD ./python -c 'import newinter'
create new thread
Exception ignored deletion of interned string failedFatal Python error: _PyInterpreterState_GET: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)
Python runtime state: finalizing (tstate=0x0000000000c51390)

Current thread 0x00007f329308a640 (most recent call first):
  File "<frozen importlib._bootstrap>", line 241 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 855 in exec_module
  File "<frozen importlib._bootstrap>", line 688 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027 in _find_and_load
  File "<frozen importlib._bootstrap>", line 1207 in _install_external_importers
Aborted (core dumped)

(4)

$ PYTHONPATH=$PWD ./python -c 'import newinter'
create new thread
Fatal Python error: _Py_CheckSlotResult: Slot __setitem__ of type dict succeeded with an exception set
Python runtime state: finalizing (tstate=0x0000000000f0e390)

Thread 0xTraceback (most recent call last):
00007fb4a331b640 (most recent call first):
<no Python frame>
Aborted (core dumped)

----------
components: C API
files: newinter.c
messages: 390626
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Py_NewInterpreter() cannot be called from a thread which has no Python thread state
versions: Python 3.10
Added file: https://bugs.python.org/file49950/newinter.c

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

From report at bugs.python.org  Fri Apr  9 10:13:11 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Apr 2021 14:13:11 +0000
Subject: [New-bugs-announce] [issue43794] OpenSSL 3.0.0: Handle
 UNEXPECTED_EOF_WHILE_READING / wrap SSL_OP_IGNORE_UNEXPECTED_EOF
Message-ID: <1617977591.38.0.697961461689.issue43794@roundup.psfhosted.org>


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

OpenSSL 3.0.0 state machine handles unexpected EOFs more strict and requires peers to properly shut down connections. The old OpenSSL 1.1.1 behavior can be get back with SSL_OP_IGNORE_UNEXPECTED_EOF.

I propose to add the option by default until Python's ssl module has better ways to perform one-way shutdown of connections.

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html

> Some TLS implementations do not send the mandatory close_notify alert on shutdown. If the application tries to wait for the close_notify alert but the peer closes the connection without sending it, an error is generated. When this option is enabled the peer does not need to send the close_notify alert and a closed connection will be treated as if the close_notify alert was received.

> You should only enable this option if the protocol running over TLS can detect a truncation attack itself, and that the application is checking for that truncation attack.

----------
assignee: christian.heimes
components: SSL
messages: 390632
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: OpenSSL 3.0.0: Handle UNEXPECTED_EOF_WHILE_READING / wrap SSL_OP_IGNORE_UNEXPECTED_EOF
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  9 11:43:50 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 09 Apr 2021 15:43:50 +0000
Subject: [New-bugs-announce] [issue43795] Implement PEP 652 -- Maintaining
 the Stable ABI
Message-ID: <1617983030.95.0.501839301811.issue43795@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

This issue tracks implementation of PEP 652.

CPython's Limited C-API and Stable ABI, introduced in PEP 384, will be formalized in a single definitive file, tested, and documented.

----------
messages: 390638
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Implement PEP 652 -- Maintaining the Stable ABI
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr  9 12:50:34 2021
From: report at bugs.python.org (Jared Ondricek)
Date: Fri, 09 Apr 2021 16:50:34 +0000
Subject: [New-bugs-announce] [issue43796] "install" package on PyPI
Message-ID: <1617987034.78.0.497462487894.issue43796@roundup.psfhosted.org>


New submission from Jared Ondricek <flamableconcrete at gmail.com>:

I recently accidentally typed "pip install pip install <package-i-really wanted>" and it installed a package called "install" that has 1 star on GitHub. It is also in use by 2.3k repositories according to the GitHub dependency graph view. I don't think it's malicious, but it does seem a bit sketchy. I just know this sort of thing has been in the news lately, and maybe this is that sort of thing that ought to be looked at by someone smarter than me about security stuff.

The way Perl deals with this specific issue is by using a specific dummy module so no one can do this on accident.

Is this worth the time to discuss? Or am I just being paranoid about a third party library called install?

PyPI entry: https://pypi.org/project/install/
GitHub page: https://github.com/eugenekolo/pip-install
GitHub projects that depend on it: https://github.com/eugenekolo/pip-install/network/dependents?package_id=UGFja2FnZS0xMjU0NTI3MDI5
Perl dummy install module: https://metacpan.org/pod/install

----------
messages: 390647
nosy: flamableconcrete
priority: normal
severity: normal
status: open
title: "install" package on PyPI
type: security

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

From report at bugs.python.org  Fri Apr  9 15:11:31 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 09 Apr 2021 19:11:31 +0000
Subject: [New-bugs-announce] [issue43797] Improve syntax error for invalid
 comparisons
Message-ID: <1617995491.91.0.835586864843.issue43797@roundup.psfhosted.org>


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

Improve syntax error for invalid comparisons such as:

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

to print:

>>> if x = 3:
  File "<stdin>", line 1
    if x = 3:
         ^
SyntaxError: cannot assign to name. Maybe you meant '==' or ':=' instead of '='?

instead

----------
messages: 390659
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for invalid comparisons

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

From report at bugs.python.org  Fri Apr  9 16:28:56 2021
From: report at bugs.python.org (Matthew Suozzo)
Date: Fri, 09 Apr 2021 20:28:56 +0000
Subject: [New-bugs-announce] [issue43798] Add position metadata to alias AST
 type
Message-ID: <1618000136.49.0.849749645286.issue43798@roundup.psfhosted.org>


New submission from Matthew Suozzo <matthew.suozzo at gmail.com>:

Given the increasing use of long `from typing import foo, bar, ...` import sequences, it's becoming more desirable to address individual components of the import node. Unfortunately, the ast.alias node doesn't contain source location metadata (e.g. lineno, col_offset).

This metadata would be comparatively easy to add, backwards compatible, and would enable more precise diagnostics e.g. lints.

----------
components: Interpreter Core
messages: 390663
nosy: matthew.suozzo
priority: normal
severity: normal
status: open
title: Add position metadata to alias AST type
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr 10 05:34:20 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 10 Apr 2021 09:34:20 +0000
Subject: [New-bugs-announce] [issue43799] OpenSSL 3.0.0: define
 OPENSSL_API_COMPAT 1.1.1
Message-ID: <1618047260.96.0.943530034595.issue43799@roundup.psfhosted.org>


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

OpenSSL 1.1 introduced the macro OPENSSL_API_COMPAT to select which APIs are exposed and which deprecation warnings are shown. https://www.openssl.org/docs/manmaster/man7/OPENSSL_API_COMPAT.html

"#define OPENSSL_API_COMPAT 0x10101000L" suppresses warnings for APIs that are available in 1.1.1 and deprecated in 3.0.0.

----------
assignee: christian.heimes
components: SSL
messages: 390706
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr 10 09:08:28 2021
From: report at bugs.python.org (ntninja)
Date: Sat, 10 Apr 2021 13:08:28 +0000
Subject: [New-bugs-announce] [issue43800] os.fwalk is not exposed on macOS
Message-ID: <1618060108.26.0.358127537113.issue43800@roundup.psfhosted.org>


New submission from ntninja <alexander-pbt at ninetailed.ninja>:

Is has come to my attention that the `os.fwalk` function has been missing from the standard library on Python for macOS since 3.6, even though macOS should support the necessary OS-interfaces (as specified in POSIX.1-2008) to support that function it just doesn't appear to exist.

Due to lack of the required hardware I can unfortunately not even test this myself.

----------
components: Library (Lib)
messages: 390710
nosy: ntninja
priority: normal
severity: normal
status: open
title: os.fwalk is not exposed on macOS
type: behavior

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

From report at bugs.python.org  Sat Apr 10 09:32:49 2021
From: report at bugs.python.org (Santosh Kumbhar)
Date: Sat, 10 Apr 2021 13:32:49 +0000
Subject: [New-bugs-announce] [issue43801] Carriage Return problem in version
 v3.9.0:9cf6752
Message-ID: <1618061569.38.0.494837003994.issue43801@roundup.psfhosted.org>


New submission from Santosh Kumbhar <skumbhar1977 at yahoo.com>:

Carriage return \r provide incorrect result

----------
components: Interpreter Core
files: CarriageReturn_Issue.JPG
messages: 390714
nosy: skumbhar
priority: normal
severity: normal
status: open
title: Carriage Return problem in version v3.9.0:9cf6752
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49952/CarriageReturn_Issue.JPG

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

From report at bugs.python.org  Sat Apr 10 12:17:02 2021
From: report at bugs.python.org (Jacob Walls)
Date: Sat, 10 Apr 2021 16:17:02 +0000
Subject: [New-bugs-announce] [issue43802] Seg fault on macOS using
 multiprocessing.JoinableQueue
Message-ID: <1618071422.03.0.709836796295.issue43802@roundup.psfhosted.org>


New submission from Jacob Walls <jacobtylerwalls at gmail.com>:

macOS 10.13.6
Python 3.9.2

I can consistently reproduce a seg fault while using multiprocessing.JoinableQueue in Python 3.9.2.

My use case is the sheet music processing library music21. My fork includes a folder of 209 files I use to reproduce, running 3 cores, shown in the script below. (This is a subset of the over 1,000 files found here: https://github.com/MarkGotham/When-in-Rome/tree/master/Corpus/OpenScore-LiederCorpus
Using this set of 1,000 files reproduces nearly every time; using the 209 files I committed to my fork was enough to reproduce about 75% of the time.)

I'm a contributor to music21, so if this is an overwhelming amount of information to debug, I will gladly pare this down as much as I can or create some methods to access the multiprocessing functionality more directly. Many thanks for any assistance.


pip3 install git+https://github.com/jacobtylerwalls/music21.git at bpo-investigation

from music21 import corpus
# suggest using a unique name each attempt
lc = corpus.corpora.LocalCorpus(name='bpo-investigation')
# point to the directory of files I committed to my fork for this investigation
lc.addPath('/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/music21/bpo-files')
# parse the files using multiprocessing
# calls music21.metadata.bundles.MetadataBundle.addFromPaths()
# which calls music21.metadata.caching.process_parallel()
lc.save()

# CTRL-C to recover from seg fault
# then, wipe out the entries in .music21rc so that you can cleanly reproduce again
from music21 import environment
us = environment.UserSettings()
us['localCorporaSettings'] = {}
quit()


Process:               Python [31677]
Path:                  /Library/Frameworks/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.9.2 (3.9.2)
Code Type:             X86-64 (Native)
Parent Process:        Python [31674]
Responsible:           Python [31677]
User ID:               501

Date/Time:             2021-04-10 11:21:19.294 -0400
OS Version:            Mac OS X 10.13.6 (17G14042)
Report Version:        12
Anonymous UUID:        E7B0208A-19D6-ABDF-B3EA-3910A56B3E72

Sleep/Wake UUID:       C4B83F57-6AD1-469E-82AE-88214FAA6283

Time Awake Since Boot: 140000 seconds
Time Since Wake:       5900 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000100b3acd8
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0x100b3acd8:
--> 
    __TEXT                 00000001068bb000-00000001068bc000 [    4K] r-x/rwx SM=COW   [/Library/Frameworks/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.python.python             	0x0000000106944072 PyObject_RichCompare + 258
1   org.python.python             	0x0000000106943e9b PyObject_RichCompareBool + 43
2   org.python.python             	0x00000001069ce3c0 min_max + 624
3   org.python.python             	0x0000000106940bab cfunction_call + 59
4   org.python.python             	0x0000000106901cad _PyObject_MakeTpCall + 365
5   org.python.python             	0x00000001069d865c call_function + 876
6   org.python.python             	0x00000001069d5b8b _PyEval_EvalFrameDefault + 25371
7   org.python.python             	0x0000000106902478 function_code_fastcall + 104
8   org.python.python             	0x00000001069d85cc call_function + 732
9   org.python.python             	0x00000001069d5ad2 _PyEval_EvalFrameDefault + 25186
10  org.python.python             	0x00000001069d92c3 _PyEval_EvalCode + 2611
11  org.python.python             	0x0000000106902401 _PyFunction_Vectorcall + 289
12  org.python.python             	0x00000001069d85cc call_function + 732
13  org.python.python             	0x00000001069d5ad2 _PyEval_EvalFrameDefault + 25186
14  org.python.python             	0x00000001069d92c3 _PyEval_EvalCode + 2611
15  org.python.python             	0x0000000106902401 _PyFunction_Vectorcall + 289
16  org.python.python             	0x0000000106901b05 _PyObject_FastCallDictTstate + 293
17  org.python.python             	0x00000001069026e8 _PyObject_Call_Prepend + 152
18  org.python.python             	0x000000010695be85 slot_tp_init + 165
19  org.python.python             	0x00000001069573d9 type_call + 345
20  org.python.python             	0x0000000106901cad _PyObject_MakeTpCall + 365
21  org.python.python             	0x00000001069d865c call_function + 876
22  org.python.python             	0x00000001069d5af3 _PyEval_EvalFrameDefault + 25219
23  org.python.python             	0x0000000106902478 function_code_fastcall + 104
24  org.python.python             	0x00000001069044ba method_vectorcall + 202
25  org.python.python             	0x00000001069d85cc call_function + 732
26  org.python.python             	0x00000001069d5af3 _PyEval_EvalFrameDefault + 25219
27  org.python.python             	0x0000000106902478 function_code_fastcall + 104
28  org.python.python             	0x00000001069d85cc call_function + 732
29  org.python.python             	0x00000001069d5ad2 _PyEval_EvalFrameDefault + 25186
30  org.python.python             	0x0000000106902478 function_code_fastcall + 104
31  org.python.python             	0x00000001069d85cc call_function + 732
32  org.python.python             	0x00000001069d5ad2 _PyEval_EvalFrameDefault + 25186
33  org.python.python             	0x0000000106902478 function_code_fastcall + 104
34  org.python.python             	0x00000001069d85cc call_function + 732
35  org.python.python             	0x00000001069d5ad2 _PyEval_EvalFrameDefault + 25186
36  org.python.python             	0x00000001069d92c3 _PyEval_EvalCode + 2611
37  org.python.python             	0x0000000106902401 _PyFunction_Vectorcall + 289
38  org.python.python             	0x00000001069d85cc call_function + 732
39  org.python.python             	0x00000001069d5ad2 _PyEval_EvalFrameDefault + 25186
40  org.python.python             	0x0000000106902478 function_code_fastcall + 104
41  org.python.python             	0x00000001069d85cc call_function + 732
42  org.python.python             	0x00000001069d5b8b _PyEval_EvalFrameDefault + 25371
43  org.python.python             	0x00000001069d92c3 _PyEval_EvalCode + 2611
44  org.python.python             	0x0000000106902401 _PyFunction_Vectorcall + 289
45  org.python.python             	0x00000001069d85cc call_function + 732
46  org.python.python             	0x00000001069d5c21 _PyEval_EvalFrameDefault + 25521
47  org.python.python             	0x00000001069d92c3 _PyEval_EvalCode + 2611
48  org.python.python             	0x00000001069cf74b PyEval_EvalCode + 139
49  org.python.python             	0x0000000106a21fc4 PyRun_StringFlags + 356
50  org.python.python             	0x0000000106a21e15 PyRun_SimpleStringFlags + 69
51  org.python.python             	0x0000000106a3e367 Py_RunMain + 1047
52  org.python.python             	0x0000000106a3eaef pymain_main + 223
53  org.python.python             	0x0000000106a3eceb Py_BytesMain + 43
54  libdyld.dylib                 	0x00007fff5a148015 start + 1

----------
components: macOS
messages: 390721
nosy: jacobtylerwalls, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Seg fault on macOS using multiprocessing.JoinableQueue
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 10 21:54:33 2021
From: report at bugs.python.org (Tal Hayon)
Date: Sun, 11 Apr 2021 01:54:33 +0000
Subject: [New-bugs-announce] [issue43803] ctypes string_at/wstring_at
Message-ID: <1618106073.56.0.0553736134144.issue43803@roundup.psfhosted.org>


New submission from Tal Hayon <talhayon1 at gmail.com>:

string_at and wstring_at first argument in docs in address but actually in code is ptr.

See
https://github.com/python/cpython/blob/750f484752763fe9ac1d6455780aabcb67f25508/Lib/ctypes/__init__.py#L513
https://github.com/python/cpython/blob/750f484752763fe9ac1d6455780aabcb67f25508/Lib/ctypes/__init__.py#L525

Noticed this when going over stubtest errors in typeshed.
See pull request https://github.com/python/typeshed/pull/5204

----------
components: ctypes
messages: 390761
nosy: talhayon1
priority: normal
severity: normal
status: open
title: ctypes string_at/wstring_at
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 11 06:51:41 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Sun, 11 Apr 2021 10:51:41 +0000
Subject: [New-bugs-announce] [issue43804] Add more info about building C/C++
 Extensions on Windows using MSVC
Message-ID: <1618138301.06.0.442096626289.issue43804@roundup.psfhosted.org>


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

In the context of Docs/extending/windows.rst, the command provided, for compiling the source code and linking the libraries to create a DLL, only works for Python 32-bit versions. But the documentation doesn't inform anything about that. The PR linked with this issue adds a note section with the text :-

"""

The above commands are only applicable for Python 32-bit versions.

"""

This PR is against the master branch and if accepted, it needs to be backported to all the previous supported versions.

Kindly have a review of my PR.

Thanking you,

With Regards

----------
assignee: docs at python
components: Documentation
messages: 390773
nosy: docs at python, shreyanavigyan
priority: normal
severity: normal
status: open
title: Add more info about building C/C++ Extensions on Windows using MSVC
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 11 07:52:50 2021
From: report at bugs.python.org (Marko)
Date: Sun, 11 Apr 2021 11:52:50 +0000
Subject: [New-bugs-announce] [issue43805] multiprocessing.Queue hangs when
 process on other side dies
Message-ID: <1618141970.93.0.19986621438.issue43805@roundup.psfhosted.org>


New submission from Marko <ivanovic.marko at yandex.com>:

When child process dies unexpectedly Queue.get waits indefinitely.

Here is example:

import os
import signal
import multiprocessing

def child_func(qa, qb):
    input = qa.get()
    print('Child received: ', input)
    os.kill(os.getpid(), signal.SIGTERM)
    qb.put('B')
    exit(0)

qa = multiprocessing.Queue()
qb = multiprocessing.Queue()
process = multiprocessing.Process(target=child_func, args=(qa, qb))
process.start()

qa.put('A')
try:
    input = qb.get()
    print('Parent received: ', input)
except Exception as ex:
    print(ex)
process.join()
exit(0)

----------
components: Library (Lib)
messages: 390774
nosy: kormang
priority: normal
severity: normal
status: open
title: multiprocessing.Queue hangs when process on other side dies
versions: Python 3.8

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

From report at bugs.python.org  Sun Apr 11 08:17:49 2021
From: report at bugs.python.org (Marko)
Date: Sun, 11 Apr 2021 12:17:49 +0000
Subject: [New-bugs-announce] [issue43806] asyncio.StreamReader hangs when
 reading from pipe and other process exits unexpectedly
Message-ID: <1618143469.5.0.154132734242.issue43806@roundup.psfhosted.org>


New submission from Marko <ivanovic.marko at yandex.com>:

When using asyncio to read from pipe, if process on the other side of pipe crashes read operation hangs indefinitely.

Example:


import asyncio
import contextlib
import os
import signal
import time

prx, ctx = os.pipe()

read_transport = None
read_stream = None

async def _connect_read(loop):
    global read_transport
    global read_stream
    stream_reader = asyncio.StreamReader()
    def protocol_factory():
        return asyncio.StreamReaderProtocol(stream_reader)
    rpipe = os.fdopen(prx, mode='r')

    transport, _ = await loop.connect_read_pipe(protocol_factory, rpipe)
    read_transport = transport
    read_stream = stream_reader

def close():
    read_transport.close()

@contextlib.asynccontextmanager
async def connect():
    try:
        loop = asyncio.get_event_loop()
        await _connect_read(loop)
        yield
    finally:
        close()

cpid = os.fork()
if cpid == 0:
    os.kill(os.getpid(), signal.SIGKILL)
    os.write(ctx, b'A')
    time.sleep(10.0)
else:
    async def read_from_child():
        async with connect():
            input = await read_stream.read(1)
            print('Parent received: ', input)

    asyncio.run(read_from_child())

----------
components: Library (Lib)
messages: 390778
nosy: kormang
priority: normal
severity: normal
status: open
title: asyncio.StreamReader hangs when reading from pipe and other process exits unexpectedly
versions: Python 3.8

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

From report at bugs.python.org  Sun Apr 11 08:25:48 2021
From: report at bugs.python.org (Unknown Retired Guy)
Date: Sun, 11 Apr 2021 12:25:48 +0000
Subject: [New-bugs-announce] [issue43807] JSONDecodeError: Extra Data Raised
 on Long Valid JSON
Message-ID: <1618143948.32.0.607083588761.issue43807@roundup.psfhosted.org>


New submission from Unknown Retired Guy <filipetaleshipolitosoares73 at gmail.com>:

https://i.ibb.co/tYqBsQ8/pico-hard.png

That JSONDecodeError: Extra Data is raised when the Valid JSON is too long or over than 25000 bytes, I don't know what caused this, can you fix it?

The code and the traceback is in that picture/link above in this comment and the long valid JSON is provided here.

The Below picture/link proof that it's a valid JSON:
https://i.ibb.co/fGytRFC/946.png

----------
components: Library (Lib)
files: pico-hard.json
messages: 390781
nosy: filipetaleshipolitosoares73
priority: normal
severity: normal
status: open
title: JSONDecodeError: Extra Data Raised on Long Valid JSON
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49953/pico-hard.json

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

From report at bugs.python.org  Sun Apr 11 10:53:35 2021
From: report at bugs.python.org (JimmyCarlos)
Date: Sun, 11 Apr 2021 14:53:35 +0000
Subject: [New-bugs-announce] [issue43808] Add .isfloat() method to str
Message-ID: <1618152815.46.0.189413617211.issue43808@roundup.psfhosted.org>


New submission from JimmyCarlos <jonathansagnella at yahoo.com>:

Hello Python Community!

One feature I think would be helpful would be a method to see if a str can be safely converted into a float. Currently, this is not doable without a long regex or a try-except block, as numbers like "-3.52" contain non-numeric symbols.

My suggestion is to make a new boolean method on the str class. Code-wise, it would behave quite similarly to this code:

def isfloat(s:str) -> bool:
    try:
        float(s)
        return True
    except:
        return False


I appreciate your feedback, so what do you all think?

----------
messages: 390785
nosy: JimmyCarlos
priority: normal
severity: normal
status: open
title: Add .isfloat() method to str
type: enhancement

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

From report at bugs.python.org  Sun Apr 11 17:49:23 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 11 Apr 2021 21:49:23 +0000
Subject: [New-bugs-announce] [issue43809] Improve mismatching parentheses
 error
Message-ID: <1618177763.07.0.220270371715.issue43809@roundup.psfhosted.org>


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

Consider the following program:

( a + b + c ] )

The current error is:

>>> ( a + b + c ] )
  File "<stdin>", line 1
    ( a + b + c ] )
                ^
SyntaxError: closing parenthesis ']' does not match opening parenthesis '('

Which is not bad, but the problem is not that the "(" is not closed (it is) but that the "]" was never opened. An improvement would be:

>>> ( a + b + c ] )
  File "<stdin>", line 1
    ( a + b + c ] )
                ^
SyntaxError: closing parenthesis ']' was never opened

----------
messages: 390798
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve mismatching parentheses error

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

From report at bugs.python.org  Mon Apr 12 01:24:45 2021
From: report at bugs.python.org (Rene Visser)
Date: Mon, 12 Apr 2021 05:24:45 +0000
Subject: [New-bugs-announce] [issue43810] os.path.abspath returns invalid
 path (resolves symbolic link)
Message-ID: <1618205085.71.0.310776377701.issue43810@roundup.psfhosted.org>


New submission from Rene Visser <renevisser at gmail.com>:

According to the python documentation os.path.abspath() does *not* resolve symbolic links. This however does not always seem to be true causing an invalid path return by abspath. This could potentially be exploited to crash python applications.

Example for bug reproduction on a linux terminal:
1. create a sub-directory "bug_abspath"
2. enter the sub-dir "bug_abspath"
3. create a symbolic link "local_link" onto the current dir using: "ln -s . local_link"
4. open python session and import os and enter the following:
5. path_correct = os.path.abspath('./../bug_abspath')  # returns correct path
6. path_invalid = os.path.abspath('local_link/../bug_abspath')  # returns invalid path with wrongly resolved "local_link"

>From step 5 the correct/valid path is returned, from step 6 abspath returns an invalid path that is non-existing (contains non-existing "bug_abspath/bug_abspath" string. 
I consider this behavior incorrect and interpret it as a bug in the abspath routine which is not allowed to resolve the symbolic link "local_link".
(Note os.path.realpath works as expected but is unwanted by me).

Tested on
OS: linux ubuntu 20.04, CentOS 7.8
PY: python 3.7 and 3.8

Thanks for any help, best wishes, Rene

----------
components: IO
messages: 390818
nosy: rvisser
priority: normal
severity: normal
status: open
title: os.path.abspath returns invalid path (resolves symbolic link)
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Apr 12 04:38:07 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Apr 2021 08:38:07 +0000
Subject: [New-bugs-announce] [issue43811] Run GHA CI with multiple OpenSSL
 versions
Message-ID: <1618216687.81.0.190201617408.issue43811@roundup.psfhosted.org>


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

CI only tests one OpenSSL version, but Python supports multiple versions of OpenSSL. OpenSSL 1.0.2, 1.1.0, 1.1.1, and 3.0.0 have different APIs and behave differently. We should run minimal tests with all major OpenSSL versions to ensure that Python compiles and works with supported versions.

This will slow down CI a bit. I figured out how to include ccache to speed up compilation a lot. With populated ccache configure + make takes less than 30 seconds instead of 90 seconds.

I also noticed that GHA action configuration compiles Python with custom OpenSSL but fails to set rpath / LD_LIBRARY_PATH. I think this means that we compile with custom OpenSSL but actual tests use OSS' OpenSSL libraries.

----------
assignee: christian.heimes
components: SSL, Tests
messages: 390825
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Run GHA CI with multiple OpenSSL versions
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 12 07:35:12 2021
From: report at bugs.python.org (Jeppe Dakin)
Date: Mon, 12 Apr 2021 11:35:12 +0000
Subject: [New-bugs-announce] [issue43812] Tuple unpacking in getitem
Message-ID: <1618227312.63.0.479595083771.issue43812@roundup.psfhosted.org>


New submission from Jeppe Dakin <dakinjeppe at gmail.com>:

This is similar to issue 32117 (I'm the author of the StackOverflow query referenced within it), which extends the tuple unpacking syntax to a small corner of the language: https://bugs.python.org/issue32117

Currently tuple unpacking is disallowed within getitem (brackets):
d = {(1, 2, 3): 42}
t = (2, 3)
d[1, *t]  # SyntaxError

To make it work, explicit parenthesization is needed:
d[(1, *t)]  # OK


On top of being slightly more neat, the un-parenthesized version is more in harmony with the language generally:

1) Parentheses are usually only required in order to distinguish between several possible outcomes (grouping). This is not the case here, as leaving out the parentheses doesn't produce any outcome at all.

2) Sub-expressions can usually be extracted as a variable. That is, one would expect the illegal code
d[1, *t]  # SyntaxError
to be equivalent to the legal code
sub = 1, *t
d[sub]  # OK

3) The following are both allowed and equivalent:
d[1, 2, 3]
d[(1, 2, 3)]
where both gets transformed into d.__getitem__((1, 2, 3)), implying that implicit tuple packing occurs in the first case. Having this tuple packing feature without allowing for the * unpacking operator feels incomplete.

4) What the syntax d[1, *t] is supposed to mean is obvious, enough so that I was surprised to find that it was disallowed. Though hardly a stumbling block, I suspect many have written such code, gotten the SyntaxError and remedied the code by putting in the (apparently non-superfluous) parentheses.


I propose allowing such tuple unpacking within getitem [], which I believe amounts to a slight adjustment of the grammar. This should not break any existing code as it merely extends the space of allowed syntax.

----------
components: Interpreter Core
messages: 390838
nosy: dakinjeppe
priority: normal
severity: normal
status: open
title: Tuple unpacking in getitem
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr 12 09:17:08 2021
From: report at bugs.python.org (Mohammed Dief)
Date: Mon, 12 Apr 2021 13:17:08 +0000
Subject: [New-bugs-announce] [issue43813] Denial of service on http.server
 module with large request method.
Message-ID: <1618233428.41.0.905190325792.issue43813@roundup.psfhosted.org>


New submission from Mohammed Dief <mdaif1332 at gmail.com>:

- Hello there, 2 days ago i discovered a DoS on http.server in python that allows me to take any python http.server down using less than 1k requests. i reported it to PSRT but they said i should report it here since http.server isn't for production. so here's the issue, in server.py http.server library has a really big value on the validation. and check if the first line of the request (method /path HTTP/VERSION) have more than 65k characters inside of it using `len()` function.

- In this case, the user is able to provide a method with 65k characters long and the server will accept it, if you send one request with this number of characters inside of the request using cURL. you will notice that the server could handle it. but after creating a big loop of 1k requests with the same characters. the server was taken down and didn't response again since it was trying to process this amount of data.

- Such an attack could be used to take down any python server running using http.server module. but since it's not for production like the documentations said the attack surface isn't that wide.

- To proof this issue, you can use this command while running your server on port 8080 or any port you just need to modify the command: for i in $(python3 -c "print('A\n'*10000)"); do curl -X $(python3 -c "print('A'*10000)") 'http://localhost:8080/404' ; done

- Then the server should be taken down after many requests, also, i managed to fix this issue from my side by adding characters validation on the code to avoid interacting with the long data many times. should i submit it here. or should i create a PR? PS, my fix doesn't change the main requestline validation int.

----------
messages: 390849
nosy: demonia
priority: normal
severity: normal
status: open
title: Denial of service on http.server module with large request method.
type: security
versions: Python 3.6

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

From report at bugs.python.org  Mon Apr 12 09:55:17 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 12 Apr 2021 13:55:17 +0000
Subject: [New-bugs-announce] [issue43814] Fix the error message for
 disallowed __weakref__ slots
Message-ID: <1618235717.97.0.321047672472.issue43814@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

When

```
TypeError: __weakref__ slot disallowed: either we already got one, or __itemsize__ != 0
```

is raised, the second condition `base->tp_itemsize != 0` (i.e. the base is a *variable-length* type, like `int`, `tuple` and `bytes`) in the error message is impossible since using a non-empty `__slots__` (e.g. `__slots__ = ('__weakref__',)`) for a subtype of a variable-length type raises a

```
TypeError: nonempty __slots__ not supported for subtype of '?'
```

earlier in the `type.__new__` implementation.

----------
components: Interpreter Core
messages: 390851
nosy: maggyero
priority: normal
severity: normal
status: open
title: Fix the error message for disallowed __weakref__ slots
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 12 10:23:27 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 12 Apr 2021 14:23:27 +0000
Subject: [New-bugs-announce] [issue43815] documentation for
 types.new_class() mention misleading default for exec_body
Message-ID: <1618237407.5.0.0559454407816.issue43815@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

https://github.com/python/cpython/blob/3.8/Lib/types.py

The documentation says "If no callback is provided, it has the same effect as passing in lambda ns: ns."

I read this as saying that the callback should return the namespace, but in reality the return value is ignored. I think the lambda should be "lambda ns: None".

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 390854
nosy: docs at python, eric.smith
priority: normal
severity: normal
status: open
title: documentation for types.new_class() mention misleading default for exec_body
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 12 11:16:23 2021
From: report at bugs.python.org (Andrew V. Jones)
Date: Mon, 12 Apr 2021 15:16:23 +0000
Subject: [New-bugs-announce] [issue43816] Missing 'extern "C"' for
 _Py_ctype_table
Message-ID: <1618240583.63.0.52966531603.issue43816@roundup.psfhosted.org>


New submission from Andrew V. Jones <andrewvaughanj at gmail.com>:

With Python 3.9.4, and when compiling with Visual Studio 2019, we have noticed that the variable `_Py_ctype_table` is *not* scoped with in an `extern "C"` block, and where the Python library (`python39.lib`) *has* been compiled with a C compiler.

This causes an issue when trying to refer to `_Py_ctype_table` from a C++ file, as the compiler tries to name-mangle the _use_ of `_Py_ctype_table`, but the linker cannot then tie the mangled name to non-mangled named from  `python39.lib`.

Example:

```
#include "Python.h"
int main() { return _Py_ctype_table[0]; }
```

Compilation:

```
cl.exe /Fe:test.exe /TP /I include test.cpp /link libs/python39.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29336 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 14.28.29336.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
libs/python39.lib
test.obj
test.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) unsigned int const * const _Py_ctype_table" (__imp_?_Py_ctype_table@@3QBIB) referenced in function main
test.exe : fatal error LNK1120: 1 unresolved externals
```

With `cl.exe`:

```
cl.exe /Bv  
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29336 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Compiler Passes:
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\cl.exe:        Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c1.dll:        Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c1xx.dll:      Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c2.dll:        Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c1xx.dll:      Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\link.exe:      Version 14.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\mspdb140.dll:  Version 14.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\1033\clui.dll: Version 19.28.29336.0
```

A na?ve check of Python.h (e126547c07) seems to suggest that:

    * There are 82 includes

    * 64 of these contain `extern "C"`

    * 8 do not contain `extern "C"`

    * The remaining 10 are either system includes or pyconfig.h

For the 8 that *do not* contain `extern "C"`, none of these use `PyAPI_DATA`. This leads me to believe that it is an oversight that `pyctype.h` does not have `extern "C"`

----------
messages: 390855
nosy: andrewvaughanj
priority: normal
severity: normal
status: open
title: Missing 'extern "C"' for _Py_ctype_table
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 12 13:39:44 2021
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 12 Apr 2021 17:39:44 +0000
Subject: [New-bugs-announce] [issue43817] Add typing.eval_annotations()
Message-ID: <1618249184.39.0.525270769302.issue43817@roundup.psfhosted.org>


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

Currently, with PEP 563 looming over us, people who use annotations for something besides type hints are kind of stuck.  Converting stringized annotations back into useful values is a complicated problem, and there's only function in the standard library that will do it for you: typing.get_type_hints().  However, typing.get_type_hints() deals specifically with *type hints*.  Type hints are a subset of annotations, and they have an additional set of rules they want to obey.  As such typing.get_type_hints() is quite opinionated and makes additional changes to the annotations that someone who only wants to un-stringize their annotations likely does not want.

I therefore propose adding a new function to typing:

    typing.get_annotations(o)

This would behave similarly to typing.get_type_hints(o), except it would be agnostic about the contents of the annotations.  It would simply evaluate them, without further changing them as typing.get_type_hints() does.  Specifically:

* It would ignore the "__no_type_check__" attribute.
* It would not wrap string annotations with ForwardRef().
* It would not wrap values with Optional[].
* It would not turn an annotation of None into type(None).
* It would not otherwise change the value of the annotation, in case I missed any.

Since the two functions would be so similar, hopefully either they would share a common implementation, or typing.get_type_hints() could be implemented on top of typing.get_annotations().

Guido, Eric, any thoughts?

----------
components: Library (Lib)
messages: 390874
nosy: eric.smith, gvanrossum, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Add typing.eval_annotations()
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr 12 16:17:28 2021
From: report at bugs.python.org (Joseph Ishac)
Date: Mon, 12 Apr 2021 20:17:28 +0000
Subject: [New-bugs-announce] [issue43818] Email does not apply policy to
 multipart messages with defects
Message-ID: <1618258648.79.0.562101023353.issue43818@roundup.psfhosted.org>


New submission from Joseph Ishac <jishac at nasa.gov>:

I have noticed an issue (Python 3.8.5) where an email can be read in as bytes, but will not be returned as such with the as_bytes() call if the message is multipart, has a boundary which is not properly quoted, and the message has non-ascii text. It seems to be a result of how multipart messages are treated if the NoBoundaryInMultipartDefect is encountered [See Test #1].

I would argue that attempting to output the test message in the sample script with an 8bit, utf-8 enabled policy should return the original bytes as the 8bit policy should be applied to the "body" portion (any part after the null lines) of the email (as would be the case if it were not multipart) [See Test #4]

Currently it appears that the entire message is treated as headers, applying the strict 7bit, ascii requirement to the entire contents of the message. Furthermore, the msg.preamble is None.

I am also uncertain that attempting to leverage the handle_defect hooks would be helpful as correcting the boundary doesn't seem to work unless you re-parse the message [See Tests #2 and #3]

So the requested change would be to apply the encoding output policy to all portions of a message after the null line ending the headers.

----------
components: email
files: email.multipart.test.py
messages: 390897
nosy: barry, jishac, r.david.murray
priority: normal
severity: normal
status: open
title: Email does not apply policy to multipart messages with defects
versions: Python 3.8
Added file: https://bugs.python.org/file49955/email.multipart.test.py

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

From report at bugs.python.org  Mon Apr 12 16:54:59 2021
From: report at bugs.python.org (Ian H)
Date: Mon, 12 Apr 2021 20:54:59 +0000
Subject: [New-bugs-announce] [issue43819] ExtensionFileLoader Does Not
 Implement invalidate_caches
Message-ID: <1618260899.84.0.216826895775.issue43819@roundup.psfhosted.org>


New submission from Ian H <insertinterestingnamehere at gmail.com>:

Currently there's no easy way to get at the internal cache of module spec objects for compiled extension modules. See https://github.com/python/cpython/blob/20ac34772aa9805ccbf082e700f2b033291ff5d2/Python/import.c#L401-L415. For example, these module spec objects continue to be cached even if we call importlib.invalidate_caches. ExtensionFileLoader doesn't implement the corresponding method for this.

The comment in the C file referenced above implies this is done this way to avoid re-initializing extension modules. I'm not sure if this can be fixed, but I figured I'd ask for input. Our use-case is an academic project where we've been experimenting with building an interface for linker namespaces into Python to allow for (among other things) loading multiple copies of any module without explicit support from that module. We've been able to do this without having custom builds of Python. We've instead gone the route of overriding some of the import machinery at runtime. To make this work we need a way to prevent caching of previous import-related information about a specific extension module. We currently have to rely on an unfortunate hack to get access to the internal cache of module spec objects for extension modules and modify that dictionary manually. What we have works, but any sort of alternative would be welcome.

----------
messages: 390905
nosy: Ian.H
priority: normal
severity: normal
status: open
title: ExtensionFileLoader Does Not Implement invalidate_caches
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 12 17:12:10 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 12 Apr 2021 21:12:10 +0000
Subject: [New-bugs-announce] [issue43820] Remove namespace copy from
 dataclasses.make_dataclass()
Message-ID: <1618261930.36.0.318460450157.issue43820@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

In make_dataclasses(), the "namespace" argument is copied because it is mutated. This isn't really necessary: the callback passed to types.new_class() could just update its "ns" parameter with "namespace" and with the new attributes (__anotations__ and default field values).

This would eliminate the need to copy "namespace".

----------
assignee: eric.smith
components: Library (Lib)
messages: 390907
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Remove namespace copy from dataclasses.make_dataclass()
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr 12 18:11:20 2021
From: report at bugs.python.org (=?utf-8?q?Josef_Havr=C3=A1nek?=)
Date: Mon, 12 Apr 2021 22:11:20 +0000
Subject: [New-bugs-announce] [issue43821] Undocumented behavior of sleep
 functions and asyncio delayed execution
Message-ID: <1618265480.34.0.661337068336.issue43821@roundup.psfhosted.org>


New submission from Josef Havr?nek <jhpepa at gmail.com>:

Hi i found undocumented behavior of time.sleep, and call_at / call_later from asyncio loop


There are two things to properly document/consider.
It is time of delay/sleep when time for python stops  (aka computer is going to hibernate/Cpu not runing) because time is relative from view of RTC(real time clock) and program both is correct 

curent behavior on
Python 3.9.4 (tags/v3.9.4:1f2e308, Apr  6 2021, 13:40:21) [MSC v.1928 64 bit (AMD64)] on win32

There is  time.sleep , asyncio.sleep and call_later 
They stall for time that has pased for program not on RTC (so it may take time) they not resume when time already passed in real word

then there is loop.call_at

there in in doc  two kinda contradicadictory statements.
and that is 
"This method?s behavior is the same as call_later()"

"and Schedule callback to be called at the given absolute timestamp when (an int or a float), using the same time reference as loop.time()."

thing is it should be legal acording to 1st qoute use
loop.call_at(seconds_to_sleep, lambda:print("something usefull")

but acording to 2nd we should use 
loop.call_at(seconds_to_sleep+loop.time(), lambda:print("something usefull")

and They Both execute after seconds_to_sleep! this is a bug because time to sleep cant be bigger than curent loop.time() then it would execute at incorect time.


Also there is second bug
loop.call_at(seconds_to_sleep+loop.time(), lambda:print("something usefull")

Even this is acording to me(how i understood from doc correct usage)
This will efectively behave as call_later because it will not call callback when seconds_to_sleep already passed since submission

however using
loop.call_at(seconds_to_sleep, lambda:print("something usefull")
will invoke as soon as program resumed from hybernation/when missed

i think loop.call_at(seconds_to_sleep, lambda:print("something usefull") should not wait seconds_to_sleep when it is smaller then loop.time() and just execute it

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 390914
nosy: Josef Havr?nek, docs at python
priority: normal
severity: normal
status: open
title: Undocumented behavior of sleep functions and asyncio delayed execution
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 12 21:30:43 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 13 Apr 2021 01:30:43 +0000
Subject: [New-bugs-announce] [issue43822] Improve syntax errors for missing
 commas
Message-ID: <1618277443.81.0.695650412986.issue43822@roundup.psfhosted.org>


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

Given that is quite common to forgot a comma in containers, function calls, ...etc and that the current error is:

>>> [a, b, c d]
  File "<stdin>", line 1
    [a, b, c d]
             ^
SyntaxError: invalid syntax

We could improve the user experience quite a lot if we mention that probably the user forgot a comma:

>>> [a, b, c d]
  File "<stdin>", line 1
    [a, b, c d]
             ^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

----------
messages: 390916
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax errors for missing commas

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

From report at bugs.python.org  Mon Apr 12 22:05:47 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 13 Apr 2021 02:05:47 +0000
Subject: [New-bugs-announce] [issue43823] Improve syntax errors for invalid
 dictionary literals
Message-ID: <1618279547.58.0.105219171129.issue43823@roundup.psfhosted.org>


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

Currently the error for invalid dict literals is generic:

>>> {1:2, 3:}
  File "<stdin>", line 1
    {1:2, 3:}
            ^
SyntaxError: invalid syntax
>>> {1:2, 3}
  File "<stdin>", line 1
    {1:2, 3}
           ^
SyntaxError: invalid syntax

We can have better errors for these cases, which can help with big dict literals:

>>> {1:2, 3}
  File "<stdin>", line 1
    {1:2, 3}
           ^
SyntaxError: ':' expected after dictionary key
>>> {1:2, 3:}
  File "<stdin>", line 1
    {1:2, 3:}
           ^
SyntaxError: expression expected after dictionary key and ':'

----------
messages: 390917
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax errors for invalid dictionary literals

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

From report at bugs.python.org  Mon Apr 12 23:00:23 2021
From: report at bugs.python.org (MingZhe Hu)
Date: Tue, 13 Apr 2021 03:00:23 +0000
Subject: [New-bugs-announce] [issue43824] array.array.__deepcopy__() accepts
 a parameter of any type
Message-ID: <1618282823.71.0.158081390215.issue43824@roundup.psfhosted.org>


New submission from MingZhe Hu <humingzhework at 163.com>:

The C implementation of foreign function array.array.__deepcopy__() is declared as follows:

https://github.com/python/cpython/blob/d9151cb45371836d39b6d53afb50c5bcd353c661/Modules/arraymodule.c#L855

The second argument is unused in the function body.

However, corresponding PyMethodDef is declared with `METH_O` flag, meaning one parameter should be passed to array.array.__deepcopy__() from the Python side:

https://github.com/python/cpython/blob/d9151cb45371836d39b6d53afb50c5bcd353c661/Modules/clinic/arraymodule.c.h#L30

This makes the following code legal:

```
import array
a = array.array('b',  [ord('g')])
a.__deepcopy__('str')
a.__deepcopy__(1)
a.__deepcopy__([1,'str'])
```

A parameter of ANY type can be passed to the foreign function, without effect on its semantic.

These code are clinic generated, and similar problems can be found for more foreign functions.

----------
components: Argument Clinic, Extension Modules
messages: 390918
nosy: Elaphurus, larry
priority: normal
severity: normal
status: open
title: array.array.__deepcopy__() accepts a parameter of any type
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 13 01:15:15 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 13 Apr 2021 05:15:15 +0000
Subject: [New-bugs-announce] [issue43825] Deprecation warnings in test cases
Message-ID: <1618290915.84.0.96654876493.issue43825@roundup.psfhosted.org>


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

Following deprecation warnings are raised when tests are ran with -Wall in CPython test suite. I will raise a PR for this.


0:03:48 load avg: 0.79 [ 59/427] test_cmd_line                                                                                                                          
/root/cpython/Lib/test/test_cmd_line.py:865: DeprecationWarning: invalid escape sequence \u                                                                             
  self.check_string(b"'\u1f'")

0:04:11 load avg: 0.86 [ 77/427] test_collections                                                                                                                       
/root/cpython/Lib/test/test_collections.py:1518: DeprecationWarning: Please use assertEqual instead.                                                                    
  self.assertEquals(len(s), len(items) - 1)

----------
components: Tests
messages: 390923
nosy: xtreak
priority: normal
severity: normal
status: open
title: Deprecation warnings in test cases
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 13 01:28:54 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 13 Apr 2021 05:28:54 +0000
Subject: [New-bugs-announce] [issue43826] Resource warnings in
 test_subprocess
Message-ID: <1618291734.0.0.346590897335.issue43826@roundup.psfhosted.org>


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

It seems that some of the pipe objects were not closed properly causing resource warnings. Regarding "subprocess still running warning" I guess we need to call kill() on the subprocess before exiting test_send_signal_race2. I will raise a PR for this.

?  cpython git:(master) ./python -X dev -Wall -m test test_subprocess                       
0:00:00 load avg: 0.06 Run tests sequentially
0:00:00 load avg: 0.06 [1/1] test_subprocess
/root/cpython/Lib/subprocess.py:1066: ResourceWarning: subprocess 22107 is still running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback

== Tests result: SUCCESS ==

1 test OK.

Total duration: 28.9 sec
Tests result: SUCCESS

----------
components: Tests
messages: 390924
nosy: giampaolo.rodola, gregory.p.smith, xtreak
priority: normal
severity: normal
status: open
title: Resource warnings in test_subprocess
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 13 03:57:15 2021
From: report at bugs.python.org (Vlad Hoi)
Date: Tue, 13 Apr 2021 07:57:15 +0000
Subject: [New-bugs-announce] [issue43827] abc conflicts with
 __init_subclass__
Message-ID: <1618300635.23.0.984081288048.issue43827@roundup.psfhosted.org>


New submission from Vlad Hoi <hoivladyslav at yahoo.com>:

from abc import ABC


class A:
    def __init_subclass__(self):
        pass


class B(ABC, A, name="name"):
    pass


After initialising class B, this exception occurs, because multiple "name" arguments where provided:

Traceback (most recent call last):
  File "test_abc", line 9, in <module>
    class B(ABC, A, name="name"):
TypeError: __new__() got multiple values for argument 'name'

----------
components: Extension Modules
messages: 390933
nosy: vladhoi
priority: normal
severity: normal
status: open
title: abc conflicts with __init_subclass__
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr 13 04:11:21 2021
From: report at bugs.python.org (Andy Maier)
Date: Tue, 13 Apr 2021 08:11:21 +0000
Subject: [New-bugs-announce] [issue43828] MappingProxyType accepts string
Message-ID: <1618301481.88.0.305881121954.issue43828@roundup.psfhosted.org>


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

MappingProxyType objects can currently be initialized from a string object. Given is purpose, I think this is a bug and should result in TypeError being raised.

Example code (on CPython 3.9.1):

>>> from types import MappingProxyType
>>> mp = MappingProxyType('abc')
>>> list(mp)
['a', 'b', 'c']
>>> mp.items()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'items'

Other invalid input types are properly checked:

>>> mp = MappingProxyType(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: mappingproxy() argument must be a mapping, not int

>>> mp = MappingProxyType(['a'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: mappingproxy() argument must be a mapping, not list

>>> mp = MappingProxyType(('a',))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: mappingproxy() argument must be a mapping, not tuple

----------
components: Library (Lib)
messages: 390935
nosy: andymaier
priority: normal
severity: normal
status: open
title: MappingProxyType accepts string
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 13 04:25:32 2021
From: report at bugs.python.org (Andy Maier)
Date: Tue, 13 Apr 2021 08:25:32 +0000
Subject: [New-bugs-announce] [issue43829] MappingProxyType cannot hash a
 hashable underlying mapping
Message-ID: <1618302332.9.0.266217619907.issue43829@roundup.psfhosted.org>


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

Objects of MappingProxyType do expose a __hash__() method, but if the underlying mapping is hashable, it still does not support hashing it.

Example:

Content of mp_hash.py:

------
#!/usr/bin/env python

from nocasedict import NocaseDict, HashableMixin
from types import MappingProxyType

class HashableDict(HashableMixin, NocaseDict):
    """A hashable dictionary"""
    pass

hd = HashableDict({'a': 1, 'b': 2})
print("hash(hd): {}".format(hash(hd)))

mp = MappingProxyType(hd)
print("hash(mp): {}".format(hash(mp)))
-------

Running the mp_hash.py script:

hash(hd): 3709951335832776636
Traceback (most recent call last):
  File "/Users/maiera/Projects/Python/cpython/issues/mappingproxy/./mp_hash.py", line 14, in <module>
    print("hash(mp): {}".format(hash(mp)))
TypeError: unhashable type: 'mappingproxy'

There are use cases where a function wants to return an immutable view on an internal dictionary, and the caller of the function should be able to use the returned object like a dictionary, except that it is read-only.

Note there is https://bugs.python.org/issue31209 on the inability to pickle MappingProxyType objects which was closed without adding the capability. That would fall under the same argument.

----------
components: Library (Lib)
messages: 390936
nosy: andymaier
priority: normal
severity: normal
status: open
title: MappingProxyType cannot hash a hashable underlying mapping
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 13 04:54:53 2021
From: report at bugs.python.org (Nathan Fallet)
Date: Tue, 13 Apr 2021 08:54:53 +0000
Subject: [New-bugs-announce] [issue43830] (-1) ** 0.5 returns
 (6.123233995736766e-17+1j) instead of 1j
Message-ID: <1618304093.14.0.191695728369.issue43830@roundup.psfhosted.org>


New submission from Nathan Fallet <contact at nathanfallet.me>:

Complex exponentiation doesn't work as expected:

```
>>> (-1) ** 0.5
(6.123233995736766e-17+1j)
```

I think the issue is linked with this part of the code:
https://github.com/python/cpython/blob/32bd68c839adb7b42af12366ab0892303115d1d1/Objects/complexobject.c#L142-L151

----------
messages: 390939
nosy: NathanFallet
priority: normal
severity: normal
status: open
title: (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 13 06:59:54 2021
From: report at bugs.python.org (=?utf-8?q?Lum=C3=ADr_Balhar?=)
Date: Tue, 13 Apr 2021 10:59:54 +0000
Subject: [New-bugs-announce] [issue43831] sqlite: convert_timestamp raises
 ValueError for empty columns
Message-ID: <1618311594.99.0.0340525219314.issue43831@roundup.psfhosted.org>


New submission from Lum?r Balhar <frenzy.madness at gmail.com>:

Hello.

I've discovered this issue when I was debugging a test failure in IPython. See this issue for more details (not needed): https://github.com/ipython/ipython/issues/12906

I'm testing this on Fedora Linux with Python 3.10.0a7 from our RPM package with SQLite 3.35.4.

I have a very simple SQLite database:

# sqlite3 test.sqlite 
SQLite version 3.35.4 2021-04-02 15:20:15
Enter ".help" for usage hints.
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE sessions (session integer
                        primary key autoincrement, start timestamp,
                        end timestamp, num_cmds integer, remark text);
INSERT INTO sessions VALUES(1,'2021-04-13 09:44:58.903345',NULL,NULL,'');
DELETE FROM sqlite_sequence;
INSERT INTO sqlite_sequence VALUES('sessions',1);
COMMIT;

When I query it without special converters, it works well:

# python3
>>> import sqlite3
>>> conn = sqlite3.connect('test.sqlite')
>>> c = conn.cursor()
>>> c.execute("SELECT * from sessions where session == 1").fetchone()
(1, '2021-04-13 09:44:58.903345', None, None, '')
>>>

but with detect_types=sqlite3.PARSE_DECLTYPES, it fails to parse the date and time:

# python3
>>> import sqlite3
>>> conn = sqlite3.connect('test.sqlite', detect_types=sqlite3.PARSE_DECLTYPES)
>>> c = conn.cursor()
>>> c.execute("SELECT * from sessions where session == 1").fetchone()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.10/sqlite3/dbapi2.py", line 67, in convert_timestamp
    datepart, timepart = val.split(b" ")
ValueError: not enough values to unpack (expected 2, got 1)
>>>

With help of pdb in ipython, I've discovered that the value convert_timestamp gets to parse is an empty bytestring:

In [5]: c.execute("SELECT * from sessions where session == 1").fetchone()                     
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-5-c234e57285e4> in <module>
----> 1 c.execute("SELECT * from sessions where session == 1").fetchone()

/usr/lib64/python3.10/sqlite3/dbapi2.py in convert_timestamp(val)
     65 
     66     def convert_timestamp(val):
---> 67         datepart, timepart = val.split(b" ")
     68         year, month, day = map(int, datepart.split(b"-"))
     69         timepart_full = timepart.split(b".")

ValueError: not enough values to unpack (expected 2, got 1)
> /usr/lib64/python3.10/sqlite3/dbapi2.py(67)convert_timestamp()
     65 
     66     def convert_timestamp(val):
---> 67         datepart, timepart = val.split(b" ")
     68         year, month, day = map(int, datepart.split(b"-"))
     69         timepart_full = timepart.split(b".")

ipdb> val                                                                                     
b''
ipdb>

Is anything in my database wrong? It seems that the content of the start column is correct and covert_timestamp should be able to parse it. Is it possible that the troublemaker here is the empty column `end` of type timestamp?

Answer to my own question: yes, the issue here is that the column `end` is of type timestamp and it's empty. If I update it with a date and time, everything works:

# sqlite3 test.sqlite
sqlite> update sessions set end='2021-04-14 09:44:58.903345' where session = 1;
sqlite> select * from sessions;
1|2021-04-13 09:44:58.903345|2021-04-14 09:44:58.903345||
sqlite>

# python3
>>> import sqlite3
>>> conn = sqlite3.connect('test.sqlite', detect_types=sqlite3.PARSE_DECLTYPES)
>>> c = conn.cursor()
>>> c.execute("SELECT * from sessions where session == 1").fetchone()
(1, datetime.datetime(2021, 4, 13, 9, 44, 58, 903345), datetime.datetime(2021, 4, 14, 9, 44, 58, 903345), None, '')

So, the final question is whether this is correct behavior. I believe that columns without content should not be passed to converters.

----------
components: Library (Lib)
messages: 390953
nosy: frenzy
priority: normal
severity: normal
status: open
title: sqlite: convert_timestamp raises ValueError for empty columns
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 13 11:50:47 2021
From: report at bugs.python.org (Andrei Pozolotin)
Date: Tue, 13 Apr 2021 15:50:47 +0000
Subject: [New-bugs-announce] [issue43832] asyncio + multiprocessing = core
 dump in sem_trywait
Message-ID: <1618329047.14.0.057176308941.issue43832@roundup.psfhosted.org>


New submission from Andrei Pozolotin <andrei.pozolotin at gmail.com>:

every attempt to touch multiprocessing.Event.is_set()
from asyncio.run() results in reproducible core dump in sem_trywait

system: Linux 5.11.8

Linux work3 5.11.8-arch1-1 #1 SMP PREEMPT Sun, 21 Mar 2021 01:55:51 +0000 x86_64 GNU/Linux

Python: 3.9.2

https://archlinux.org/packages/extra/x86_64/python/

----------
components: asyncio
files: dump_core.py
messages: 390973
nosy: Andrei Pozolotin, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio + multiprocessing = core dump in sem_trywait
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49956/dump_core.py

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

From report at bugs.python.org  Tue Apr 13 14:27:19 2021
From: report at bugs.python.org (sco1)
Date: Tue, 13 Apr 2021 18:27:19 +0000
Subject: [New-bugs-announce] [issue43833] Unexpected Parsing of Numeric
 Literals Concatenated with Boolean Operators
Message-ID: <1618338439.83.0.0166317758112.issue43833@roundup.psfhosted.org>


New submission from sco1 <sco1.git at gmail.com>:

Came across this riddle today:

>>> [0x_for x in (1, 2, 3)]
[15]

Initially I thought this was related to PEP 515 but the unexpected behavior extends to simpler examples as well, such as:

>>> x = 5
>>> 123or x
123
>>> 123and x
5

I'm not familiar enough with C to understand why this is being parsed/tokenized this way, but this seems like it should instead be a SyntaxError. This appears to be fairly old behavior, as the non-underscored version works back to at least 2.7.

And a bonus:

>>> 0x1decade or more
31378142

----------
messages: 390981
nosy: sco1
priority: normal
severity: normal
status: open
title: Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 13 16:02:35 2021
From: report at bugs.python.org (John Hagen)
Date: Tue, 13 Apr 2021 20:02:35 +0000
Subject: [New-bugs-announce] [issue43834] Use context manager in StringIO
 example
Message-ID: <1618344155.0.0.639710984937.issue43834@roundup.psfhosted.org>


New submission from John Hagen <johnthagen at gmail.com>:

The example for StringIO currently manually closes the object rather than using a context manager. Since this is likely the first code that a new user encounters and context managers reduce error-prone situations, I think it would be helpful to show usage as a context manager.

https://docs.python.org/3/library/io.html#io.StringIO.getvalue

Something like:

import io

with io.StringIO() as output:
    output.write('First line.\n')
    print('Second line.', file=output)

    # Retrieve file contents -- this will be
    # 'First line.\nSecond line.\n'
    contents = output.getvalue()

# Context manager will automatically close
# object and discard memory buffer --
# .getvalue() will now raise an exception.

----------
assignee: docs at python
components: Documentation
messages: 391000
nosy: John Hagen, docs at python
priority: normal
severity: normal
status: open
title: Use context manager in StringIO example
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 13 18:21:40 2021
From: report at bugs.python.org (Paul Pinterits)
Date: Tue, 13 Apr 2021 22:21:40 +0000
Subject: [New-bugs-announce] [issue43835] Dataclasses don't call base class
 __init__
Message-ID: <1618352500.63.0.0280826468162.issue43835@roundup.psfhosted.org>


New submission from Paul Pinterits <rawing7 at gmail.com>:

It's documented behavior that @dataclass won't generate an __init__ method if the class already defines one. It's also documented that a dataclass may inherit from another dataclass.

But what happens if you inherit from a dataclass that implements a custom __init__? Well, that custom __init__ is never called:

```
import dataclasses

@dataclasses.dataclass
class Foo:
    foo: int
    
    def __init__(self, *args, **kwargs):
        print('Foo.__init__')  # This is never printed

@dataclasses.dataclass
class Bar(Foo):
    bar: int

obj = Bar(1, 2)
print(vars(obj))  # {'foo': 1, 'bar': 2}
```

So if a dataclass uses a custom __init__, all its child classes must also use a custom __init__. This is 1) incredibly inconvenient, and 2) bad OOP. A child class should (almost) always chain-call its base class's __init__.

----------
components: Library (Lib)
messages: 391006
nosy: Paul Pinterits
priority: normal
severity: normal
status: open
title: Dataclasses don't call base class __init__
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 14 00:11:46 2021
From: report at bugs.python.org (Kaleb Barrett)
Date: Wed, 14 Apr 2021 04:11:46 +0000
Subject: [New-bugs-announce] [issue43836] range.index doesn't support
 start/stop optional arguments
Message-ID: <1618373506.04.0.457958304296.issue43836@roundup.psfhosted.org>


New submission from Kaleb Barrett <dev.ktbarrett at gmail.com>:

The range builtin type is a collections.abc.Sequence, which in Python 3.5 added the optional start and stop arguments to the index method of Sequences. However, range.index does not support these optional arguments required by Sequence.

I noticed this when creating a wrapper type around range which was a  Sequence. mypy complained 'Signature of "index" incompatible with supertype "Sequence"', but attempting to pass the values raised 'TypeError: index() takes exactly one argument (3 given)'.

----------
components: Library (Lib)
messages: 391029
nosy: ktbarrett
priority: normal
severity: normal
status: open
title: range.index doesn't support start/stop optional arguments
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 14 00:38:05 2021
From: report at bugs.python.org (Aidan Feldman)
Date: Wed, 14 Apr 2021 04:38:05 +0000
Subject: [New-bugs-announce] [issue43837] Operator precedence documentation
 could be more clear
Message-ID: <1618375085.85.0.211628673766.issue43837@roundup.psfhosted.org>


New submission from Aidan Feldman <aidan.feldman at gmail.com>:

I am teaching a class on Python for people who are new to coding, and I was talking them through the operator precedence table:

https://docs.python.org/3/reference/expressions.html#operator-precedence

A couple things that confused the students:

- "Highest precedence" is on the bottom, while "lowest precedence" is on top
- There isn't any mention of variables. While not operators, probably worth mentioning that they (effectively?) have higher precedence than any of the operators.

I'd be happy to try making my first contribution to Python if there's interest in those edits. Also, I have an example breaking down operator precedence in practice here, which I could include:

https://colab.research.google.com/github/afeld/python-public-policy/blob/main/lecture_2.ipynb#scrollTo=UTxeT5RvqSFl

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 391030
nosy: aidan.feldman, docs at python
priority: normal
severity: normal
status: open
title: Operator precedence documentation could be more clear
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Apr 14 03:34:28 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Apr 2021 07:34:28 +0000
Subject: [New-bugs-announce] [issue43838] There is a way to access an
 underlying mapping in MappingProxyType
Message-ID: <1618385668.86.0.518778578496.issue43838@roundup.psfhosted.org>


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

The purpose of MappingProxyType is to provide a read-only proxy for mapping. It should not expose the underlying mapping because it would invalidate the purpose of read-only proxy. But there is a way to do this using comparison operator:

from types import MappingProxyType

orig = {1: 2}
proxy = MappingProxyType(orig)

class X:
    def __eq__(self, other):
        other[1] = 3

assert proxy[1] == 2
proxy == X()
assert proxy[1] == 3
assert orig[1] == 3

In particularly it allows to modify __dict__ of builtin types.

----------
components: Interpreter Core
messages: 391039
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: There is a way to access an underlying mapping in MappingProxyType
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 14 06:59:49 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 10:59:49 +0000
Subject: [New-bugs-announce] [issue43839] [easy] test_cmd_line:
 DeprecationWarning: invalid escape sequence \u
Message-ID: <1618397989.34.0.985444339357.issue43839@roundup.psfhosted.org>


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

Does someone want to propose a fix for the following warning?

$ ./python -m test test_cmd_line
0:00:00 load avg: 6.45 Run tests sequentially
0:00:00 load avg: 6.45 [1/1] test_cmd_line
/home/vstinner/python/master/Lib/test/test_cmd_line.py:865: DeprecationWarning: invalid escape sequence \u
  self.check_string(b"'\u1f'")

== Tests result: SUCCESS ==

1 test OK.

Total duration: 15.9 sec
Tests result: SUCCESS

----------
components: Tests
keywords: easy, newcomer friendly
messages: 391053
nosy: vstinner
priority: normal
severity: normal
status: open
title: [easy] test_cmd_line: DeprecationWarning: invalid escape sequence \u
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 14 07:06:17 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 11:06:17 +0000
Subject: [New-bugs-announce] [issue43840] [easy] test_distutils logs 3
 DeprecationWarning warnings
Message-ID: <1618398377.82.0.479453704615.issue43840@roundup.psfhosted.org>


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

test_distutils logs 3 DeprecationWarning warnings. They are emitted on purpose and related to PEP 632.

Does someone want to propose a fix for that?

"with self.assertWarns(DeprecationWarning):" or warnings_helper.check_warnings() of test.support.warnings_helper can be used.


$ ./python -m test -v test_distutils 
(...)
0:00:00 load avg: 5.49 [1/1] test_distutils
/home/vstinner/python/master/Lib/test/test_distutils.py:8: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  import distutils.tests

(...)

test_byte_compile_optimized (distutils.tests.test_build_py.BuildPyTestCase) ... /tmp/tmpptdx9r50.py:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  from distutils.util import byte_compile
ok

(...)

test_byte_compile (distutils.tests.test_install_lib.InstallLibTestCase) ... /tmp/tmpk_cfc09q.py:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  from distutils.util import byte_compile
ok

(...)

Tests result: SUCCESS

--

By the way, it would be nice to ignore the DeprecationWarning in setup.py as well for now:

$ make
(...)
/home/vstinner/python/master/./setup.py:33: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  from distutils import log
(...)

This warning is annoying.

----------
components: Tests
keywords: easy, newcomer friendly
messages: 391054
nosy: vstinner
priority: normal
severity: normal
status: open
title: [easy] test_distutils logs 3 DeprecationWarning warnings

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

From report at bugs.python.org  Wed Apr 14 07:09:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 11:09:23 +0000
Subject: [New-bugs-announce] [issue43841] [easy] test_collections:
 DeprecationWarning: Please use assertEqual instead
Message-ID: <1618398563.11.0.755110442609.issue43841@roundup.psfhosted.org>


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

Does someone want to propose a fix?

$ ./python -m test -v test_collections 
(...)
test_issue_4920 (test.test_collections.TestCollectionABCs) ... /home/vstinner/python/master/Lib/test/test_collections.py:1518: DeprecationWarning: Please use assertEqual instead.
  self.assertEquals(len(s), len(items) - 1)
ok
(...)
Tests result: SUCCESS


Warning introduced by PR 25209:

commit 453074c8daf996b1815a0cd2218f0dbf1801056c
Author: Stepan Sindelar <me at stevesindelar.cz>
Date:   Thu Apr 8 01:31:55 2021 +0200

    Fix broken test for MutableSet.pop() (GH-25209)
    
    Changes the test to not assert concrete result of pop, but just that it
    was an item from the set, and that the set shrunk by one.

----------
components: Tests
keywords: easy, newcomer friendly
messages: 391056
nosy: vstinner
priority: normal
severity: normal
status: open
title: [easy] test_collections: DeprecationWarning: Please use assertEqual instead
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 14 07:15:16 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 11:15:16 +0000
Subject: [New-bugs-announce] [issue43842] test_logging: "OSError: [Errno 9]
 Bad file descriptor" logged on FreeBSD
Message-ID: <1618398916.84.0.57759722491.issue43842@roundup.psfhosted.org>


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

Random error seen on FreeBSD:

0:05:54 load avg: 5.75 [340/427/1] test_logging passed -- running: test_pydoc (34.4 sec)

Exception in thread Thread-25 (serve_forever):
Traceback (most recent call last):
  File "/usr/home/vstinner/python/master/Lib/threading.py", line 990, in _bootstrap_inner
    self.run()
  File "/usr/home/vstinner/python/master/Lib/threading.py", line 928, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/vstinner/python/master/Lib/test/test_logging.py", line 863, in serve_forever
    asyncore.loop(poll_interval, map=self._map)
  File "/usr/home/vstinner/python/master/Lib/asyncore.py", line 203, in loop
    poll_fun(timeout, map)
  File "/usr/home/vstinner/python/master/Lib/asyncore.py", line 144, in poll
    r, w, e = select.select(r, w, e, timeout)
OSError: [Errno 9] Bad file descriptor

----------
components: Tests
messages: 391057
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_logging: "OSError: [Errno 9] Bad file descriptor" logged on FreeBSD
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 14 07:20:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 11:20:23 +0000
Subject: [New-bugs-announce] [issue43843] libregrtest: mark a test as failed
 if a thread logs an unexpected exception
Message-ID: <1618399223.2.0.989011891247.issue43843@roundup.psfhosted.org>


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

The Python test runner (libregrtest) should mark a test as failed if a thread logs an unexpected exception, as already done with unraisable exception.

See for example bpo-43842 where test_logging logs the following exception, but the tes is marked as passed:

Exception in thread Thread-25 (serve_forever):
Traceback (most recent call last):
  File "/usr/home/vstinner/python/master/Lib/threading.py", line 990, in _bootstrap_inner
    self.run()
  File "/usr/home/vstinner/python/master/Lib/threading.py", line 928, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/vstinner/python/master/Lib/test/test_logging.py", line 863, in serve_forever
    asyncore.loop(poll_interval, map=self._map)
  File "/usr/home/vstinner/python/master/Lib/asyncore.py", line 203, in loop
    poll_fun(timeout, map)
  File "/usr/home/vstinner/python/master/Lib/asyncore.py", line 144, in poll
    r, w, e = select.select(r, w, e, timeout)
OSError: [Errno 9] Bad file descriptor


Attached PR implements this change.

----------
components: Tests
messages: 391059
nosy: vstinner
priority: normal
severity: normal
status: open
title: libregrtest: mark a test as failed if a thread logs an unexpected exception
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 14 07:38:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 11:38:57 +0000
Subject: [New-bugs-announce] [issue43844] [easy]
Message-ID: <1618400337.77.0.971562000748.issue43844@roundup.psfhosted.org>


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

<string>:2: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+

$ ./python -m test -v test_lib2to3
(...)
test_load_grammar_from_subprocess (lib2to3.tests.test_parser.TestPgen2Caching) ... <string>:2: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
ok
(...)
Tests result: SUCCESS

Command to only re-run this test:

./python -Werror -m test -v test_lib2to3 -m test_load_grammar_from_subprocess

----------
messages: 391062
nosy: vstinner
priority: normal
severity: normal
status: open
title: [easy]

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

From report at bugs.python.org  Wed Apr 14 07:57:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2021 11:57:40 +0000
Subject: [New-bugs-announce] [issue43845] test_concurrent_futures leaks many
 dangling threads on FreeBSD
Message-ID: <1618401460.69.0.519102056132.issue43845@roundup.psfhosted.org>


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

test_idle_process_reuse_multiple() of test_concurrent_futures failed on AMD64 FreeBSD Shared 3.x, but then passed when re-run in verbose mode.
https://buildbot.python.org/all/#/builders/483/builds/1073

Moreover, test_concurrent_futures leaked many dangling threads.


0:04:31 load avg: 1.95 [163/427/1] test_concurrent_futures failed (3 min 29 sec) -- running: test_nntplib (2 min 17 sec)
Warning -- threading_cleanup() failed to cleanup 2 threads (count: 2, dangling: 3)
Warning -- Dangling thread: <_ExecutorManagerThread(Thread-41, started 34386025472)>
Warning -- Dangling thread: <_MainThread(MainThread, started 34374492160)>
Warning -- Dangling thread: <Thread(QueueFeederThread, started daemon 34418515968)>
Warning -- threading_cleanup() failed to cleanup -2 threads (count: 0, dangling: 1)
Warning -- Dangling thread: <_MainThread(MainThread, started 34374492160)>
(...)
======================================================================
FAIL: test_idle_process_reuse_multiple (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_concurrent_futures.py", line 1018, in test_idle_process_reuse_multiple
    self.assertLessEqual(len(executor._processes), 2)
AssertionError: 3 not less than or equal to 2

Stdout:
0.43s 

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

Ran 226 tests in 209.441s

FAILED (failures=1, skipped=6)
test test_concurrent_futures failed
(...)
1 re-run test:
    test_concurrent_futures

Total duration: 16 min 7 sec
Tests result: FAILURE then SUCCESS

----------
components: Tests
messages: 391070
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures leaks many dangling threads on FreeBSD
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 14 08:09:31 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 14 Apr 2021 12:09:31 +0000
Subject: [New-bugs-announce] [issue43846] Control stack usage in large
 expressions
Message-ID: <1618402171.48.0.736532073467.issue43846@roundup.psfhosted.org>


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

Large literals or function calls with many arguments can consume a lot of stack space.

This will be a problem for any future work to use a contiguous stack for data and possibly eliminate frame objects for most calls.

It is also possible (I haven't measured this) that this large stack consumption is hurting performance now, as it might leak memory by leaving giant frames in the free-list or as a zombie frame.

This fix relatively straightforward. For large literals and argument lists, build them incrementally rather than all at once.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 391072
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Control stack usage in large expressions
type: performance

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

From report at bugs.python.org  Wed Apr 14 08:51:02 2021
From: report at bugs.python.org (ed)
Date: Wed, 14 Apr 2021 12:51:02 +0000
Subject: [New-bugs-announce] [issue43847] realpath of bytestr smb drive
 letters fail
Message-ID: <1618404662.92.0.914724176997.issue43847@roundup.psfhosted.org>


New submission from ed <ed at ene>:

some win7sp1 and win10:20H2 boxes cannot realpath a networked drive letter such as b"n:" (also affects b"n:\\")
 * observed with 3.8.7 and 3.9.1
 * 3.7.9 is fine

requirements to trigger:
 * bytestring (not unicode str)
 * just the drive letter (subfolders are ok)
 * networked drive (regular disks and vmhgfs are ok)
 * enterprise/AD network? (doesn't seem to happen with samba)

hits the following exceptions in succession:
 * access denied at L601: "path = _getfinalpathname(path)"
 * "cant concat str to bytes" at L621: "return path + tail"

----------
components: Windows
messages: 391074
nosy: 9001, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: realpath of bytestr smb drive letters fail
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 14 14:30:43 2021
From: report at bugs.python.org (Joachim)
Date: Wed, 14 Apr 2021 18:30:43 +0000
Subject: [New-bugs-announce] [issue43848] gzip.py: explain optional argument
 mtime
Message-ID: <1618425043.16.0.353574460502.issue43848@roundup.psfhosted.org>


New submission from Joachim <j.wuttke at fz-juelich.de>:

Explain the data type of optional argument mtime: seconds since the epoch.

As an alternative to mtime = None, recommend mtime = 0 for generating deterministic streams.

----------
assignee: docs at python
components: Documentation
messages: 391093
nosy: docs at python, j5w6
priority: normal
severity: normal
status: open
title: gzip.py: explain optional argument mtime
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 14 16:52:07 2021
From: report at bugs.python.org (John)
Date: Wed, 14 Apr 2021 20:52:07 +0000
Subject: [New-bugs-announce] [issue43849] Typo in calendar doc
Message-ID: <1618433527.59.0.488396025411.issue43849@roundup.psfhosted.org>


New submission from John <john at jcoppens.com>:

I believe the parenthesis in 

calendar.firstweekday()

should be removed. As it is, it produces 'int' cannot be called.

----------
assignee: docs at python
components: Documentation
messages: 391098
nosy: JohnCC330, docs at python
priority: normal
severity: normal
status: open
title: Typo in calendar doc
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 14 18:31:26 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Wed, 14 Apr 2021 22:31:26 +0000
Subject: [New-bugs-announce] [issue43850] unreproducible bytecode: set order
 depends on random seed for compiled bytecode
Message-ID: <1618439486.71.0.574977757021.issue43850@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

Currently, the order of set or frozenset elements when saved to bytecode is dependent on the random seed. This breaks reproducibility.

Example fail from an Arch Linux package: https://reproducible.archlinux.org/api/v0/builds/88454/diffoscope

Let's take an example file, `test_compile.py`
```python
s = {
    'aaa',
    'bbb',
    'ccc',
    'ddd',
    'eee',
}
```

$ PYTHONHASHSEED=0 python -m compileall --invalidation-mode checked-hash test_compile.py
$ mv __pycache__ __pycache__1
$ PYTHONHASHSEED=1 python -m compileall --invalidation-mode checked-hash test_compile.py

$ diff __pycache__/test_compile.cpython-39.pyc __pycache__1/test_compile.cpython-39.pyc
Binary files __pycache__/test_compile.cpython-39.pyc and __pycache__1/test_compile.cpython-39.pyc differ

$ diff <(xxd __pycache__/test_compile.cpython-39.pyc) <(xxd __pycache__1/test_compile.cpython-39.pyc)
5,6c5,6
< 00000040: 005a 0362 6262 5a03 6464 645a 0361 6161  .Z.bbbZ.dddZ.aaa
< 00000050: 5a03 6363 635a 0365 6565 4e29 01da 0173  Z.cccZ.eeeN)...s
---
> 00000040: 005a 0361 6161 5a03 6363 635a 0364 6464  .Z.aaaZ.cccZ.ddd
> 00000050: 5a03 6565 655a 0362 6262 4e29 01da 0173  Z.eeeZ.bbbN)...s

I believe the issue is in the marshall module. Particularly, this line[1]. My simple fix was to create a list from the set, sort it, and iterate over it instead.

[1] https://github.com/python/cpython/blob/00d7abd7ef588fc4ff0571c8579ab4aba8ada1c0/Python/marshal.c#L505

----------
messages: 391104
nosy: FFY00, Mark.Shannon, benjamin.peterson, yselivanov
priority: normal
severity: normal
status: open
title: unreproducible bytecode: set order depends on random seed for compiled bytecode
type: behavior

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

From report at bugs.python.org  Wed Apr 14 19:16:08 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 14 Apr 2021 23:16:08 +0000
Subject: [New-bugs-announce] [issue43851] Optimise SQLite builds on macOS
 and Windows
Message-ID: <1618442168.97.0.98960637018.issue43851@roundup.psfhosted.org>


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

We should apply some of the recommended "optimisation" compile-time options[1] to the SQLite builds for the macOS and Windows installers. The following options should be safe to apply:

- SQLITE_DEFAULT_MEMSTATUS=0
- SQLITE_LIKE_DOESNT_MATCH_BLOBS
- SQLITE_MAX_EXPR_DEPTH=0
- SQLITE_OMIT_DEPRECATED
- SQLITE_OMIT_AUTOINIT

I'm not sure about SQLITE_DEFAULT_WAL_SYNCHRONOUS=1.

Quoting the SQLite docs:
"So these options do not make a huge difference. But in some design situations, every little bit helps."


[1] https://sqlite.org/compile.html

----------
components: Windows, macOS
messages: 391109
nosy: erlendaasland, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Optimise SQLite builds on macOS and Windows
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 15 05:23:35 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 15 Apr 2021 09:23:35 +0000
Subject: [New-bugs-announce] [issue43852] [sqlite3] Harden tuple creation
Message-ID: <1618478615.92.0.752682980963.issue43852@roundup.psfhosted.org>


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

All but one of the PyTuple_SetItem() calls are executed without checking the return value.

Callers:
$ grep -r PyTuple_SetItem Modules/_sqlite 
Modules/_sqlite/connection.c:        PyTuple_SetItem(args, i, cur_py_value);
Modules/_sqlite/cursor.c:        PyTuple_SetItem(row, i, converted);
Modules/_sqlite/cursor.c:    if (PyTuple_SetItem(func_args, 0, Py_NewRef(operation)) != 0) {
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 0, column_name);
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 1, Py_NewRef(Py_None));
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 2, Py_NewRef(Py_None));
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 3, Py_NewRef(Py_None));
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 4, Py_NewRef(Py_None));
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 5, Py_NewRef(Py_None));
Modules/_sqlite/cursor.c:                PyTuple_SetItem(descriptor, 6, Py_NewRef(Py_None));
Modules/_sqlite/cursor.c:                PyTuple_SetItem(self->description, i, descriptor);


All of these are operating on newly created tuples, so I suggest replacing them with PyTuple_SET_ITEM() instead of adding error handling.


For the users in _pysqlite_query_execute() I also suggest to move the tuple creation closer to the code that fills it, in order to minimise the number of decref's needed in case of error.

----------
components: Extension Modules
files: patch.diff
keywords: patch
messages: 391122
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] Harden tuple creation
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49960/patch.diff

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

From report at bugs.python.org  Thu Apr 15 06:00:09 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 15 Apr 2021 10:00:09 +0000
Subject: [New-bugs-announce] [issue43853] [sqlite] Fix sqlite3_value_text()
 usage
Message-ID: <1618480809.83.0.17163581819.issue43853@roundup.psfhosted.org>


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

Fix sqlite3_value_text() usage:
- Raise MemoryError if sqlite3_value_text() sets SQLITE_NOMEM
- Let PyUnicode_FromStringAndSize() errors propagate

Quoting the SQLite docs:
"As long as the input parameter is correct, these routines can only fail if an out-of-memory error occurs"


See also:
- bpo-43296
- https://sqlite.org/c3ref/value_blob.html

----------
components: Extension Modules
files: patch.diff
keywords: patch
messages: 391124
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite] Fix sqlite3_value_text() usage
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49961/patch.diff

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

From report at bugs.python.org  Thu Apr 15 06:17:59 2021
From: report at bugs.python.org (darrikonn)
Date: Thu, 15 Apr 2021 10:17:59 +0000
Subject: [New-bugs-announce] [issue43854] curses: returns incorrect chars
 after resuming a suspended process
Message-ID: <1618481879.49.0.746081524149.issue43854@roundup.psfhosted.org>


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

Using the arrow keys after resuming a suspended process yields `27 (escape)` from `getch`/`get_wch`/...

Steps to reproduce:

```
# test.py
from curses import wrapper

def main(stdscr):
    # Clear screen
    stdscr.clear()

    key = 0
    while key != 27:
    	key = stdscr.getch()
        stdscr.addstr(0, 0, str(key))

    stdscr.refresh()

wrapper(main)
```

1. python test.py
2. ctrl-z
3. fg
4. <arrow_down>

This gives the char `27` which is the escape character and therefore exits the python script.

----------
components: Library (Lib)
messages: 391126
nosy: darrikonn
priority: normal
severity: normal
status: open
title: curses: returns incorrect chars after resuming a suspended process
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 15 08:49:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2021 12:49:57 +0000
Subject: [New-bugs-announce] [issue43855] test_ssl:
 test_msg_callback_deadlock_bpo43577() failed on macOS of GitHub Action
Message-ID: <1618490997.04.0.782752491303.issue43855@roundup.psfhosted.org>


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

macOS of GitHub Action failed:
https://github.com/python/cpython/pull/25400/checks?check_run_id=2344085246

ERROR: test_msg_callback_deadlock_bpo43577 (test.test_ssl.TestSSLDebug)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 4799, in test_msg_callback_deadlock_bpo43577
    s.connect((HOST, server.port))
  File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1342, in connect
    self._real_connect(addr, False)
  File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1329, in _real_connect
    super().connect(addr)
ConnectionRefusedError: [Errno 61] Connection refused


Test code:

    def test_msg_callback_deadlock_bpo43577(self):
        client_context, server_context, hostname = testing_context()
        server_context2 = testing_context()[1]

        def msg_cb(conn, direction, version, content_type, msg_type, data):
            pass

        def sni_cb(sock, servername, ctx):
            sock.context = server_context2

        server_context._msg_callback = msg_cb
        server_context.sni_callback = sni_cb

        server = ThreadedEchoServer(context=server_context, chatty=False)
        with server:
            with client_context.wrap_socket(socket.socket(),
                                            server_hostname=hostname) as s:
                s.connect((HOST, server.port))
            with client_context.wrap_socket(socket.socket(),
                                            server_hostname=hostname) as s:
                s.connect((HOST, server.port))  # <===== FAIL HERE ====


test.pythoninfo:

ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1k  25 Mar 2021
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 11, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000
ssl.SSLContext.maximum_version: MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: MINIMUM_SUPPORTED
ssl.SSLContext.options: OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x80000054
ssl.SSLContext.protocol: PROTOCOL_TLS
ssl.SSLContext.verify_mode: CERT_NONE
ssl.default_https_context.maximum_version: MAXIMUM_SUPPORTED
ssl.default_https_context.minimum_version: MINIMUM_SUPPORTED
ssl.default_https_context.options: OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x80000054
ssl.default_https_context.protocol: PROTOCOL_TLS
ssl.default_https_context.verify_mode: CERT_REQUIRED
ssl.stdlib_context.maximum_version: MAXIMUM_SUPPORTED
ssl.stdlib_context.minimum_version: MINIMUM_SUPPORTED
ssl.stdlib_context.options: OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x80000054
ssl.stdlib_context.protocol: PROTOCOL_TLS
ssl.stdlib_context.verify_mode: CERT_NONE


The test was added recently:

commit 77cde5042a2f1eae489c11a67540afaf43cd5cdf
Author: Christian Heimes <christian at python.org>
Date:   Sun Mar 21 16:13:09 2021 +0100

    bpo-43577: Fix deadlock with SSLContext._msg_callback and sni_callback (GH-24957)
    
    OpenSSL copies the internal message callback from SSL_CTX->msg_callback to
    SSL->msg_callback. SSL_set_SSL_CTX() does not update SSL->msg_callback
    to use the callback value of the new context.
    
    PySSL_set_context() now resets the callback and _PySSL_msg_callback()
    resets thread state in error path.
    
    Signed-off-by: Christian Heimes <christian at python.org>

----------
components: Tests
messages: 391131
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: test_msg_callback_deadlock_bpo43577() failed on macOS of GitHub Action
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 15 11:54:10 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2021 15:54:10 +0000
Subject: [New-bugs-announce] [issue43856] Docs for importlib.metadata should
 mention Python version
Message-ID: <1618502050.6.0.847154133714.issue43856@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

https://docs.python.org/3/library/importlib.metadata.html lacks a mention of which Python version saw the introduction of `importlib.metadata` (it definitely doesn't exist in my 3.7 install, for example).

----------
components: Library (Lib)
messages: 391139
nosy: eric.araujo, ezio.melotti, jaraco, mdk, pitrou, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Docs for importlib.metadata should mention Python version
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 15 12:31:31 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 15 Apr 2021 16:31:31 +0000
Subject: [New-bugs-announce] [issue43857] Fix the AttributeError message for
 deletion of a missing attribute
Message-ID: <1618504291.99.0.55591533554.issue43857@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Compare the `AttributeError` messages in this interactive Python session:

```python
>>> class A:
...     y = 0
...     __slots__ = ('z',)
... 
>>> A().x
[?]
AttributeError: 'A' object has no attribute 'x'
>>> A().x = 1
[?]
AttributeError: 'A' object has no attribute 'x'
>>> del A().x
[?]
AttributeError: 'A' object has no attribute 'x'
>>> A().y
0
>>> A().y = 2
[?]
AttributeError: 'A' object attribute 'y' is read-only
>>> del A().y
[?]
AttributeError: 'A' object attribute 'y' is read-only
>>> A().z
[?]
AttributeError: z
>>> A().z = 3
>>> del A().z
[?]
AttributeError: z
```

with the `AttributeError` messages in that one:

```python
>>> class B: pass
... 
>>> B().x
[?]
AttributeError: 'B' object has no attribute 'x'
>>> B().x = 1
>>> del B().x
[?]
AttributeError: x
```

The message `AttributeError: x` from `del B().x` does not feel right. I expect this message to be the same as the message `AttributeError: 'B' object has no attribute 'x'` from `B().x`, since in both cases the object `B()` has no attribute `'x'`.

I have checked on PyPy 7.3.3 (Python 3.7.9) and it uses the expected message `AttributeError: 'B' object has no attribute 'x'` from `B().x` for `del B().x`. So this confirms my initial suspicion.

----

In CPython, the `AttributeError` message for attribute retrieval is implemented [here](https://github.com/python/cpython/blob/v3.9.4/Objects/object.c#L1266-L1270) (except for [slot retrieval](https://github.com/python/cpython/blob/v3.9.4/Python/structmember.c#L70-L75)):

```c
    if (!suppress) {
        PyErr_Format(PyExc_AttributeError,
                     "'%.50s' object has no attribute '%U'",
                     tp->tp_name, name);
    }
```

And the `AttributeError` messages for attribute assignment and deletion are implemented [here](https://github.com/python/cpython/blob/v3.9.4/Objects/object.c#L1324-L1350) (except for [slot deletion](https://github.com/python/cpython/blob/v3.9.4/Python/structmember.c#L112-L118)):

```c
    if (dict == NULL) {
        dictptr = _PyObject_GetDictPtr(obj);
        if (dictptr == NULL) {
            if (descr == NULL) {
                PyErr_Format(PyExc_AttributeError,
                             "'%.100s' object has no attribute '%U'",
                             tp->tp_name, name);
            }
            else {
                PyErr_Format(PyExc_AttributeError,
                             "'%.50s' object attribute '%U' is read-only",
                             tp->tp_name, name);
            }
            goto done;
        }
        res = _PyObjectDict_SetItem(tp, dictptr, name, value);
    }
    else {
        Py_INCREF(dict);
        if (value == NULL)
            res = PyDict_DelItem(dict, name);
        else
            res = PyDict_SetItem(dict, name, value);
        Py_DECREF(dict);
    }
    if (res < 0 && PyErr_ExceptionMatches(PyExc_KeyError))
        PyErr_SetObject(PyExc_AttributeError, name);
```

So it is the last line `PyErr_SetObject(PyExc_AttributeError, name);` that would be updated. Note that `_PyObjectDict_SetItem` delegates to `PyDict_DelItem` (if `value` is `NULL`) or `PyDict_SetItem` (if `value` is not `NULL`), and that only `PyDict_DelItem` can [set an exception](https://github.com/python/cpython/blob/v3.9.4/Objects/dictobject.c#L1655-L1657) `PyExc_KeyError`, which is then translated to an exception `PyExc_AttributeError` in the last line.

----------
components: Interpreter Core
messages: 391140
nosy: maggyero
priority: normal
severity: normal
status: open
title: Fix the AttributeError message for deletion of a missing attribute
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 15 13:46:57 2021
From: report at bugs.python.org (Andy Lowry)
Date: Thu, 15 Apr 2021 17:46:57 +0000
Subject: [New-bugs-announce] [issue43858] Provide method to get list of
 logging level names
Message-ID: <1618508817.95.0.500447634147.issue43858@roundup.psfhosted.org>


New submission from Andy Lowry <andrew at nglowry.com>:

It would be useful to have something like a `getLevelNames` method to return the current list of level names, ordered by priority.

This currently appears to be available only by accessing a private member, like `_levelToName` or `_nameToLevel`.

This functionality is useful, for example, in populating a `choices` list for an `argparse` option to allow a user to select a logging level when launching a program from a command line.

----------
components: Library (Lib)
messages: 391145
nosy: andylowry
priority: normal
severity: normal
status: open
title: Provide method to get list of logging level names
versions: Python 3.8

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

From report at bugs.python.org  Thu Apr 15 20:26:09 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 16 Apr 2021 00:26:09 +0000
Subject: [New-bugs-announce] [issue43859] Improve syntax error for
 indentation errors
Message-ID: <1618532769.85.0.413956426604.issue43859@roundup.psfhosted.org>


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

The current indentation error is quite simplistic and it does not include the context of the statement that was associated with the indented block and where it was:

>>> def foo():
...     if lel:
...     x = 2
  File "<stdin>", line 3
    x = 2
    ^
IndentationError: expected an indented block

we can improve the error by adding some context:

>>> def foo():
...    if lel:
...    x = 2
  File "<stdin>", line 3
    x = 2
    ^
IndentationError: expected an indented block after if statement in line 2

----------
messages: 391160
nosy: ammar2, pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for indentation errors

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

From report at bugs.python.org  Fri Apr 16 01:39:02 2021
From: report at bugs.python.org (Steve Kelem)
Date: Fri, 16 Apr 2021 05:39:02 +0000
Subject: [New-bugs-announce] [issue43860] unittest increment tests executed
Message-ID: <1618551542.77.0.0261778711624.issue43860@roundup.psfhosted.org>


New submission from Steve Kelem <steve at kelem.net>:

The unittest module (and most other unittest modules) keep a count of the number of functional tests run, as defined by the number of times testXXXX is called.

I would like the option to count the number of times that assertXXXX is called.

I have to run many tests (in unittest's sense of the word), but each of the tests consists of iterating through an array of hundreds or thousands of individual test cases with their expected results. These check for corner cases, interior, exterior cases, and for mathematical accuracy. It doesn't make sense to make a separate test case for each test value, when iterating through an array of values, and calling AssertEquals (or whatever is called for) for each expected & actual value-pair.
Yes, the existing methodology tells me that a particular functional test works, but it is important to know whether it passed based on a single test value (because the test development is not done or the tester was lazy) or whether it passed thousands of tests and will give adequate coverage. (Yes that can be cheated too, but assume that the tests are developed in earnest.)

----------
components: Tests
messages: 391166
nosy: chelmite
priority: normal
severity: normal
status: open
title: unittest increment tests executed
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 16 07:09:04 2021
From: report at bugs.python.org (Yunlongs)
Date: Fri, 16 Apr 2021 11:09:04 +0000
Subject: [New-bugs-announce] [issue43861] A potential double free in
 list_sort_impl
Message-ID: <1618571344.31.0.812788267332.issue43861@roundup.psfhosted.org>


New submission from Yunlongs <lylgood at foxmail.com>:

File: Objects/listobject.c

There is a feasible path to trigger a double free if memory limited. Details as follow:

In funtion list_sort_impl, it calls merge_collapse(&ms) at line 2,394 and there exist paths to free ms->a.keys:

merge_collapse(&ms)->merge_at(ms, n) (line 1,938) ->merge_lo(ms, ssa, na, ssb, nb) (line 1,911)->MERGE_GETMEM(ms, na) (line 1,601)->merge_freemem(ms) (line 1,565)->PyMem_Free(ms->a.keys) (line 1,545).

Then if memory is not enough, line 1,568 will return -1 and the error code will propagate to the caller list_sort_impl().

After receives the err code, list_sort_impl() goto fial and calls
merge_freemem(&ms) again to free the ms->a.keys at the second time at line 2,431.

The same problem also occurs when merge_force_collapse(&ms) is called at line 2,401.

----------
messages: 391184
nosy: Yunlongs
priority: normal
severity: normal
status: open
title: A potential double free in list_sort_impl
type: security
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 16 09:06:47 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2021 13:06:47 +0000
Subject: [New-bugs-announce] [issue43862] warnings: -W option and
 PYTHONWARNINGS now use the message as a regex
Message-ID: <1618578407.09.0.811659309688.issue43862@roundup.psfhosted.org>


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

I propose to change the -W command line option and the PYTHONWARNINGS environment variable to use the message as a regular expression in Python 3.10. Or does anyone have a reason to keep the current behavior as it is?

--

Python provides two ways to specify warnings filters:

* -W command line option: can be used multiple times
* PYTHONWARNINGS environment variable: can contain multiple options separated by commas

While the Python API warnings.filterwarnings(action, message="", ...) uses the message as a regular expression, -W and PYTHONWARNINGS require to match *exactly* the *whole* message.

For example, if you only want to ignore the new distutils deprecation warning, you must write exactly:

$ ./python -X dev -W 'ignore:The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives:DeprecationWarning' -c 'import distutils'

I use -X dev to show DeprecationWarning, or you can also use -Wdefault if you prefer.

If the deprecation warning changes in Python or if you have a single typo, the warning is not ignored. Example with a typo ("3.13" rather than "3.12"):

$ ./python -X dev -W 'ignore:The distutils package is deprecated and slated for removal in Python 3.13. Use setuptools or check PEP 632 for potential alternatives:DeprecationWarning' -c 'import distutils'
<string>:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives

The PYTHONWARNINGS has another limitation: you cannot specify a message if it contains a comma (","). Hopefully, Python doesn't raise warnings containing comma, right? Well... Just one example:

Lib/distutils/sysconfig.py:554: ? ? ? ?warnings.warn('SO is deprecated, use EXT_SUFFIX', DeprecationWarning, 2)

You cannot only ignore the message:

$ PYTHONWARNINGS='ignore:SO is deprecated, use EXT_SUFFIX:DeprecationWarning' ./python -c 'import sys; print(sys.warnoptions); print(len(sys.warnoptions))'
Invalid -W option ignored: invalid action: 'use EXT_SUFFIX'
['ignore:SO is deprecated', ' use EXT_SUFFIX:DeprecationWarning']
2

You can only try to use "module" and "lineno" parameters of a warning filter, which are more fragile and hard to use to use.

----------
components: Library (Lib)
messages: 391190
nosy: vstinner
priority: normal
severity: normal
status: open
title: warnings: -W option and PYTHONWARNINGS now use the message as a regex
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 16 09:10:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2021 13:10:40 +0000
Subject: [New-bugs-announce] [issue43863] [Windows] test_distutils logs:
 DeprecationWarning: bdist_msi command is deprecated since Python 3.9,
 use bdist_wheel (wheel packages) instead
Message-ID: <1618578640.73.0.80306334611.issue43863@roundup.psfhosted.org>


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

On Windows, test_distutils logs the warning: DeprecationWarning: "bdist_msi command is deprecated (...)". Example:

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\master>python -m test -v test_distutils
(...)
test_skip_build (distutils.tests.test_bdist.BuildTestCase) ... C:\vstinner\python\master\lib\distutils\dist.py:858: DeprecationWarning: bdist_msi command is deprecated since Python 3.9, use bdist_wheel (wheel packages) instead
  cmd_obj = self.command_obj[command] = klass(self)
ok
(...)

----------
components: Tests
messages: 391191
nosy: vstinner
priority: normal
severity: normal
status: open
title: [Windows] test_distutils logs:  DeprecationWarning: bdist_msi command is deprecated since Python 3.9, use bdist_wheel (wheel packages) instead
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 16 09:12:55 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2021 13:12:55 +0000
Subject: [New-bugs-announce] [issue43864] [Windows] test_importlib logs:
 DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and
 slated for removal in Python 3.12; use find_spec() instead
Message-ID: <1618578775.46.0.785924432695.issue43864@roundup.psfhosted.org>


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

On Windows, test_importlib logs "DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated (...)". Example:

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\master>python -m test -v test_importlib 
(...)
test_find_module_missing (test.test_importlib.test_windows.Frozen_WindowsRegistryFinderTests) ... <frozen importlib._bootstrap_external>:848: DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and slated for 
removal in Python 3.12; use find_spec() instead
ok

(...)

test_find_module_missing (test.test_importlib.test_windows.Source_WindowsRegistryFinderTests) ... C:\vstinner\python\master\lib\importlib\_bootstrap_external.py:848: DeprecationWarning: WindowsRegistryFinder.find_module() is de
precated and slated for removal in Python 3.12; use find_spec() instead
  _warnings.warn("WindowsRegistryFinder.find_module() is deprecated and "
ok

(...)

----------
components: Tests, Windows
messages: 391192
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, vstinner, xtreak, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] test_importlib logs: DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and slated for removal in Python 3.12; use find_spec() instead
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 16 10:00:31 2021
From: report at bugs.python.org (Michael Dudley)
Date: Fri, 16 Apr 2021 14:00:31 +0000
Subject: [New-bugs-announce] [issue43865] win32_ver and getwindowsversion
 return different Windows 10 build numbers
Message-ID: <1618581631.1.0.315230933416.issue43865@roundup.psfhosted.org>


New submission from Michael Dudley <emddudley at gmail.com>:

On my machine platform.win32_ver() and sys.getwindowsversion() are returning different Windows build numbers. I have confirmed this with Python 3.7.6, 3.8.5, and 3.9.2 (all 64-bit) on Windows 10.

platform.win32_ver() returns:

    ('10', '10.0.18362', 'SP0', '')

sys.getwindowsversion() returns:

    major=10, minor=0, build=18363, platform=2, service_pack=''

The sys.getwindowsversion() value is correct.

The Windows About panel reports Windows 10 Enterprise, version 1909, build 18363.1440. My kernel32.dll version is 10.0.18362.1350.

----------
components: Library (Lib), Windows
messages: 391199
nosy: emddudley, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: win32_ver and getwindowsversion return different Windows 10 build numbers
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr 16 10:07:03 2021
From: report at bugs.python.org (Muhammad Hussein Ammari)
Date: Fri, 16 Apr 2021 14:07:03 +0000
Subject: [New-bugs-announce] [issue43866] Installation files of the Python
Message-ID: <1618582023.9.0.574924434196.issue43866@roundup.psfhosted.org>


New submission from Muhammad Hussein Ammari <xmha97 at gmail.com>:

I have WhatsApp installed for all users. (on %ProgramFiles%)
Unfortunately, I just saw that installation files of the Python are stored on "%LocalAppData%\Package Cache".
Installation files should be stored on "%ProgramData%\Package Cache".
The problem now is that other users can no longer delete or update Python.
Please fix this issue.
Thanks.

----------
components: Installation, Windows
files: Untitled.png
messages: 391201
nosy: paul.moore, steve.dower, tim.golden, xmha97, zach.ware
priority: normal
severity: normal
status: open
title: Installation files of the Python
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49964/Untitled.png

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

From report at bugs.python.org  Fri Apr 16 10:41:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2021 14:41:31 +0000
Subject: [New-bugs-announce] [issue43867] concurrent.futures: handle
 explicitly SystemExit in managers.Server
Message-ID: <1618584091.17.0.579971617999.issue43867@roundup.psfhosted.org>


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

In bpo-43843, I modified libregrtest to log a warning if a thread raises an uncaught exception. test_concurrent_futures now logs two warnings.

s390x Debian 3.x:
https://buildbot.python.org/all/#/builders/49/builds/1124

AMD64 RHEL7 3.x:
https://buildbot.python.org/all/#/builders/15/builds/1074

0:03:18 load avg: 4.78 [302/427] test_concurrent_futures passed (2 min 46 sec) -- running: test_tokenize (37.8 sec), test_peg_generator (59.2 sec)
Warning -- Uncaught thread exception: SystemExit
Warning -- Uncaught thread exception: SystemExit


The problem can be seen with test_ressources_gced_in_workers():

$ ./python -m test test_concurrent_futures -m test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest.test_ressources_gced_in_workers -v
(...)
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 
Warning -- Uncaught thread exception: SystemExit
Warning -- Uncaught thread exception: SystemExit
(...)
Tests result: SUCCESS

I propose to explicitly catch this SystemExit. We can take the opportunity to call c.close() explicitly: see attached PR.

----------
components: Library (Lib)
messages: 391205
nosy: bquinlan, davin, pablogsal, pitrou, vstinner
priority: normal
severity: normal
status: open
title: concurrent.futures: handle explicitly SystemExit in managers.Server
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 16 10:48:28 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 16 Apr 2021 14:48:28 +0000
Subject: [New-bugs-announce] [issue43868] Remove
 PyOS_ReadlineFunctionPointer from the stable ABI list
Message-ID: <1618584508.44.0.195246221039.issue43868@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

The inclusion of PyOS_ReadlineFunctionPointer in python3dll.c (*) was a mistake. According to PEP 384:

> functions expecting FILE* are not part of the ABI, to avoid depending on a specific version of the Microsoft C runtime DLL on Windows.

The situation may have changed and it might be reasonable to revisit this decision, but that would call for a larger discussion. There are FILE*-taking functions that are probably much ore useful than this one. (But, I think it's a good idea to limit the stable ABI to file-like Python objects anyway.)

I see PEP 384 as being definitive (where it's not ambiguous). The python3dll.c list and public/private headers do not actually define the stable ABI.

So, I'd like to remove the function from the list.


---

(*) it was actually PC/python3.def in 3.2

----------
components: C API, Windows
messages: 391206
nosy: paul.moore, petr.viktorin, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Remove PyOS_ReadlineFunctionPointer from the stable ABI list
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 16 11:15:58 2021
From: report at bugs.python.org (Ofek Lev)
Date: Fri, 16 Apr 2021 15:15:58 +0000
Subject: [New-bugs-announce] [issue43869] Fix documentation of
 epoch/time.time
Message-ID: <1618586158.57.0.649486184749.issue43869@roundup.psfhosted.org>


New submission from Ofek Lev <ofekmeister at gmail.com>:

The descriptions for the following:

- https://docs.python.org/3/library/time.html#epoch
- https://docs.python.org/3/library/time.html#time.time

indicate that it is platform dependent. However, that is likely untrue. See the brief discussion here: https://github.com/DataDog/integrations-core/pull/6692#discussion_r427469097

----------
assignee: docs at python
components: Documentation
messages: 391214
nosy: Ofekmeister, docs at python, p-ganssle
priority: normal
severity: normal
status: open
title: Fix documentation of epoch/time.time
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr 16 11:53:05 2021
From: report at bugs.python.org (Ian H)
Date: Fri, 16 Apr 2021 15:53:05 +0000
Subject: [New-bugs-announce] [issue43870] C API Functions Bypass __import__
 Override
Message-ID: <1618588385.66.0.211694514597.issue43870@roundup.psfhosted.org>


New submission from Ian H <insertinterestingnamehere at gmail.com>:

Some of the import-related C API functions are documented as bypassing an override to builtins.__import__. This appears to be the case, but the documentation is incomplete in this regard. For example, PyImport_ImportModule is implemented by calling PyImport_Import which does respect an override to builtins.__import__, but PyImport_ImportModule doesn't mention respecting an override. On the other hand some routines (like?PyImport_ImportModuleLevelObject) do not respect an override to the builtin import.

Is this something that people are open to having fixed? I've been working on an academic project downstream that involved some overrides to the __import__ machinery (I haven't figured out a way to do this with just import hooks) and having some modules skip going through our override threw us for a bad debugging loop. The easiest long-term fix from our perspective is to patch the various PyImport routines?to always respect an __import__ override. This technically is a backwards compatibility break, but I'm unsure if anyone is actually relying on the fact that specific C API functions bypass builtins.__import__ entirely. It seems more likely that the current behavior will cause bugs downstream like it did for us.

----------
messages: 391220
nosy: Ian.H
priority: normal
severity: normal
status: open
title: C API Functions Bypass __import__ Override
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 16 13:30:08 2021
From: report at bugs.python.org (Alexei Pastuchov)
Date: Fri, 16 Apr 2021 17:30:08 +0000
Subject: [New-bugs-announce] [issue43871] urllib.parse.urlparse doesn't
 check port
Message-ID: <1618594208.69.0.606171015487.issue43871@roundup.psfhosted.org>


New submission from Alexei Pastuchov <info at maximka.de>:

It is possible to get valid ParseResult from the urlparse function even for a non-numeric port value. Only by requesting the port it fails[1].
Would it be an improvement if _checknetloc[2] validates the value of port properly?


// code snippet
Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlparse
>>> uri = 'xx://foo:bar'
>>> uri_parts = urlparse(uri)
>>> uri_parts.netloc
'foo:bar'
>>> uri_parts.port
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/urllib/parse.py", line 174, in port
    raise ValueError(message) from None
ValueError: Port could not be cast to integer value as 'bar'
// code snippet

[1] https://github.com/python/cpython/blob/e1903e11a3d42512effe336026e0c67f602e5848/Lib/urllib/parse.py#L172
[2] https://github.com/python/cpython/blob/e1903e11a3d42512effe336026e0c67f602e5848/Lib/urllib/parse.py#L416

----------
messages: 391238
nosy: palik
priority: normal
severity: normal
status: open
title: urllib.parse.urlparse doesn't check port

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

From report at bugs.python.org  Fri Apr 16 13:39:48 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Fri, 16 Apr 2021 17:39:48 +0000
Subject: [New-bugs-announce] [issue43872] Unable to compile cpython in
 Visual Studio 2019
Message-ID: <1618594788.56.0.562957194552.issue43872@roundup.psfhosted.org>


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

Recently, I'm having some problem compiling cpython from Visual Studio 2019. I'm able to compile using the build.bat script. I'm using Visual Studio 2019 for about 2-3 months now for compiling and developing cpython. But unfortunately, some error occurs. While compiling cpython from Visual Studio 2019 the asdl_c.py, if I remember correctly, raises an exception that it was passed no arguments and therefore the build fails. After I compile cpython using build.bat script I'm able to build and rebuild cpython from Visual Studio 2019 without facing any problem for 2-3 days. Then again the error occurs. Can anyone explain to why this is happening? Or is this a bug in cpython?

----------
messages: 391239
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Unable to compile cpython in Visual Studio 2019
type: compile error

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

From report at bugs.python.org  Fri Apr 16 14:16:59 2021
From: report at bugs.python.org (Roy Smith)
Date: Fri, 16 Apr 2021 18:16:59 +0000
Subject: [New-bugs-announce] [issue43873] bz2.open() docs give conflicting
 defaults for mode
Message-ID: <1618597019.31.0.436475861063.issue43873@roundup.psfhosted.org>


New submission from Roy Smith <roy at panix.com>:

See https://docs.python.org/3.7/library/bz2.html

For bz2.open(), the section header says:

bz2.open(filename, mode='r' ...)

but the text says:

The mode argument ... The default is 'rb'.

As I understand it, 'r' and 'rb' actually do the same thing, but the docs should at least be consistent.

----------
components: Library (Lib)
messages: 391245
nosy: roysmith
priority: normal
severity: normal
status: open
title: bz2.open() docs give conflicting defaults for mode
versions: Python 3.7

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

From report at bugs.python.org  Fri Apr 16 15:07:46 2021
From: report at bugs.python.org (Terence Honles)
Date: Fri, 16 Apr 2021 19:07:46 +0000
Subject: [New-bugs-announce] [issue43874] argparse crashes on subparsers
 with no dest/metava
Message-ID: <1618600066.88.0.240618154113.issue43874@roundup.psfhosted.org>


New submission from Terence Honles <terence.honles at gmail.com>:

When creating a simple required subparser the following will result in an error instead of an error message:

>>> from argparse import ArgumentParser
>>>
>>> parser = ArgumentParser()
>>> subparsers = parser.add_subparsers(required=True)
>>> subparsers.add_parser('one')
>>> subparsers.add_parser('two')
>>>
>>> parser.parse_args([])

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.8/argparse.py", line 1768, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib64/python3.8/argparse.py", line 1800, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib64/python3.8/argparse.py", line 2035, in _parse_known_args
    ', '.join(required_actions))
TypeError: sequence item 0: expected str instance, NoneType found

Looking at the code this is because the subparser is actually an action and when resolving the name it uses `None` as the subparser name which results in the error above.

----------
components: Library (Lib)
messages: 391250
nosy: terence.honles
priority: normal
pull_requests: 24176
severity: normal
status: open
title: argparse crashes on subparsers with no dest/metava
type: crash
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr 16 16:08:19 2021
From: report at bugs.python.org (Reuben Thomas)
Date: Fri, 16 Apr 2021 20:08:19 +0000
Subject: [New-bugs-announce] [issue43875] path.glob with ** does not always
 detect symlink loops
Message-ID: <1618603699.0.0.0318164618776.issue43875@roundup.psfhosted.org>


New submission from Reuben Thomas <rrt at sc3d.org>:

Example session:

$ mkdir foo
$ cd foo
$ ln -s .. bar
$ ln -s .. baz
$ python3.9
Python 3.9.0+ (default, Oct 20 2020, 08:43:38) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from glob import glob
>>> glob('**/README', recursive=True)
[HANG]

Removing either of the symlinks fixes the hang.

----------
messages: 391253
nosy: rrt
priority: normal
severity: normal
status: open
title: path.glob with ** does not always detect symlink loops

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

From report at bugs.python.org  Fri Apr 16 16:35:56 2021
From: report at bugs.python.org (Vince Reuter)
Date: Fri, 16 Apr 2021 20:35:56 +0000
Subject: [New-bugs-announce] [issue43876] argparse documentation contrasting
 nargs '*' vs. '+' is misleading
Message-ID: <1618605356.69.0.0775347773509.issue43876@roundup.psfhosted.org>


New submission from Vince Reuter <vreuter at protonmail.com>:

Standard library docs for argparse, at https://docs.python.org/3/library/argparse.html#nargs, suggest that setting nargs='+' differs from nargs='*' in that the former will raise a parsing error when the argument's omitted while the latter will not. In other words, nargs='+' sounds like it's distinguished from nargs='*' by virtue of implicitly making `required=True`. This implication isn't valid when the option name has a double-hyphen prefix, though: no argument parsing error is thrown for a double-hyphen-prefix-named option, even with `nargs='+'`. The docs neglect to mention this qualification that prevents `nargs='+'` from implicitly making the option required. Originally noticed while using a port of the library to R: https://github.com/trevorld/r-argparse/issues/31

----------
messages: 391255
nosy: vreuter
priority: normal
severity: normal
status: open
title: argparse documentation contrasting nargs '*' vs.  '+' is misleading

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

From report at bugs.python.org  Fri Apr 16 21:18:08 2021
From: report at bugs.python.org (Gene Ratzlaff)
Date: Sat, 17 Apr 2021 01:18:08 +0000
Subject: [New-bugs-announce] [issue43877] Logging Cookbook ambiguity
Message-ID: <1618622288.58.0.221543721652.issue43877@roundup.psfhosted.org>


New submission from Gene Ratzlaff <generatz at gmail.com>:

In the section titled "Logging to a single file from multiple processes"
I am puzzled by the second example, as follows:
The first example has the listener/logger is in a separate >process< and the listener/logger process is (as I would anticipate) started >before< the worker/sender processes. 
In the 2nd example, the listener/logger is in a separate >thread< and the listener/logger thread is (oddly) started >after< the worker/sender processes.
Please correct it, or explain in the Cookbook what is OK about doing it that way, and if it is OK, are there limitations to doing it that way?

----------
assignee: docs at python
components: Documentation
messages: 391267
nosy: bluebloodpole, docs at python
priority: normal
severity: normal
status: open
title: Logging Cookbook ambiguity
type: enhancement

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

From report at bugs.python.org  Sat Apr 17 01:15:18 2021
From: report at bugs.python.org (Keith Smiley)
Date: Sat, 17 Apr 2021 05:15:18 +0000
Subject: [New-bugs-announce] [issue43878] ./configure fails on Apple Silicon
Message-ID: <1618636518.04.0.898249551468.issue43878@roundup.psfhosted.org>


New submission from Keith Smiley <keithbsmiley at gmail.com>:

It seems that Apple Silicon support has been added in https://github.com/python/cpython/pull/22855, but when I try to build locally I see this error:

```
% ./configure
checking for git... found
checking build system type... Invalid configuration `arm64-apple-darwin20.3.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin20.3.0 failed
```

I went through the `autoreconf` instructions to see if the checked in configure script was outdated, but it doesn't seem to have fixed the issue.

I was able to fix this locally by updating the config.sub and config.guess files (only the former was required but I noticed in previous updates that they were updated in lockstep). I'm a bit wary about that change because it doesn't seem like they are updated frequently (they haven't been in over 3 years), but I will submit it for discussion.

----------
components: Build
messages: 391272
nosy: keith
priority: normal
severity: normal
status: open
title: ./configure fails on Apple Silicon
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr 17 05:18:44 2021
From: report at bugs.python.org (Gabriele Tornetta)
Date: Sat, 17 Apr 2021 09:18:44 +0000
Subject: [New-bugs-announce] [issue43879] Add native_id to PyThreadState
Message-ID: <1618651124.52.0.543120021636.issue43879@roundup.psfhosted.org>


New submission from Gabriele Tornetta <phoenix1987 at gmail.com>:

I would like to propose adding the native_id field to the PyThreadState structure to store the result of PyThread_get_thread_native_id. On some systems, like Linux, it is not easy to retrieve this information from outside of the Python interpreter process.

Tools like Austin (https://github.com/P403n1x87/austin) could benefit from this for CPU time sampling. Currently, if one wants to retrieve the TID from a PyThreadState instance is to regard thread_id as a pointer to a struct pthread structure, loop over all the Python threads to find the one that has the PID for TID and infer the offset of the tid field within struct pthread, which is not ideal.

----------
components: C API
messages: 391276
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: Add native_id to PyThreadState
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr 17 06:55:55 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Apr 2021 10:55:55 +0000
Subject: [New-bugs-announce] [issue43880] 3.10 SSL module deprecations
Message-ID: <1618656955.76.0.569824483108.issue43880@roundup.psfhosted.org>


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

With PEP 644 accepted I can finally raise deprecation warnings for a lot of features that have been deprecated since Python 3.6 / 3.7 or by OpenSSL 1.1.1:

* ssl.OP_NO_SSLv2
* ssl.OP_NO_SSLv3
* ssl.OP_NO_TLSv1
* ssl.OP_NO_TLSv1_1
* ssl.OP_NO_TLSv1_2
* ssl.OP_NO_TLSv1_3
* ssl.PROTOCOL_SSLv2
* ssl.PROTOCOL_SSLv3
* ssl.PROTOCOL_SSLv23 (alias for PROTOCOL_TLS)
* ssl.PROTOCOL_TLS
* ssl.PROTOCOL_TLSv1
* ssl.PROTOCOL_TLSv1_1
* ssl.PROTOCOL_TLSv1_2
* ssl.TLSVersion.SSLv3
* ssl.TLSVersion.TLSv1
* ssl.TLSVersion.TLSv1_1
* ssl.wrap_socket()
* ssl.RAND_pseudo_bytes()
* ssl.RAND_egd() (already removed since it's not supported by OpenSSL 1.1.1)

----------
assignee: christian.heimes
components: SSL
messages: 391284
nosy: christian.heimes
priority: high
severity: normal
status: open
title: 3.10 SSL module deprecations
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr 17 13:12:10 2021
From: report at bugs.python.org (Guo Ci Teo)
Date: Sat, 17 Apr 2021 17:12:10 +0000
Subject: [New-bugs-announce] [issue43881] add platform availabity
 information for os.sched_getaffinity
Message-ID: <1618679530.53.0.161636381643.issue43881@roundup.psfhosted.org>


Change by Guo Ci Teo <zguoci at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, guoci
priority: normal
severity: normal
status: open
title: add platform availabity information for os.sched_getaffinity
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 18 15:37:00 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Apr 2021 19:37:00 +0000
Subject: [New-bugs-announce] [issue43882] urllib.parse should sanitize urls
 containing ASCII newline and tabs.
Message-ID: <1618774620.3.0.412025280445.issue43882@roundup.psfhosted.org>


New submission from Senthil Kumaran <senthil at uthcode.com>:

A security issue was reported by Mike Lissner wherein an attacker was able to use `\r\n` in the url path, the urlparse method didn't sanitize and allowed those characters be present in the request.

> In [9]: from urllib.parse import urlsplit
> In [10]: urlsplit("java\nscript:alert('bad')")
> Out[10]: SplitResult(scheme='', netloc='', path="java\nscript:alert('bad')", query='', fragment='')



Firefox and other browsers ignore newlines in the scheme. From
the browser console:

>> new URL("java\nscript:alert(bad)")
<< URL { href: "javascript:alert(bad)", origin: "null", protocol:
"javascript:", username: "", password: "", host: "", hostname: "", port: "", pathname: "alert(bad)", search: "" 

Mozilla Developers informed about the controlling specification for URLs is in fact defined by the "URL Spec"
from WHATWG which updates RFC 3986 and specifies that tabs and newlines
should be stripped from the scheme.

See: https://url.spec.whatwg.org/#concept-basic-url-parser

That link defines an automaton for URL parsing. From that link, steps 2 and 3 of scheme parsing read:

If input contains any ASCII tab or newline, validation error.
3. Remove all ASCII tab or newline from input.

---- 


urlparse module behavior should be updated, and an ASCII tab or newline should be removed from the url (sanitized) before it is sent to the request, as WHATWG spec.

----------
assignee: orsenthil
messages: 391343
nosy: orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.parse should sanitize urls containing ASCII newline and tabs.
type: security
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 18 15:43:37 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Apr 2021 19:43:37 +0000
Subject: [New-bugs-announce] [issue43883] Making urlparse WHATWG conformant
Message-ID: <1618775017.08.0.625993552954.issue43883@roundup.psfhosted.org>


New submission from Senthil Kumaran <senthil at uthcode.com>:

Mike Lissner reported that a set test suites that exercise extreme conditions with URLs, but in conformance with url.spec.whatwg.org
was maintained here:

https://github.com/web-platform-tests/wpt/tree/77da471a234e03e65a22ee6df8ceff7aaba391f8/url

These test cases were used against urlparse and urljoin method.

https://gist.github.com/mlissner/4d2110d7083d74cff3893e261a801515


Quoting verbatim


```
The basic idea is to iterate over the test cases and try joining and parsing them. The script wound up messier than I wanted b/c there's a fair bit of normalization you have to do (e.g., the test cases expect blank paths to be '/', while urlparse returns an empty string), but you'll get the idea.

The bad news is that of the roughly 600 test cases fewer than half pass. Some more normalization would fix some more of this, and I don't imagine all of these have security concerns (I haven't thought through it, honestly, but there are issues with domain parsing too that look meddlesome). For now I've taken it as far as I can, and it should be a good start, I think.

The final numbers the script cranks out are:

Done. 231/586 successes. 1 skipped.
```

----------
assignee: orsenthil
messages: 391344
nosy: orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: Making urlparse WHATWG conformant
type: behavior

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

From report at bugs.python.org  Sun Apr 18 22:47:38 2021
From: report at bugs.python.org (Ronal Abraham)
Date: Mon, 19 Apr 2021 02:47:38 +0000
Subject: [New-bugs-announce] [issue43884] Cannot cleanly kill a subprocess
 using high-level asyncio APIs
Message-ID: <1618800458.29.0.766698985684.issue43884@roundup.psfhosted.org>


New submission from Ronal Abraham <ronalabraham at gmail.com>:

There doesn't appear to be a way to prematurely kill a subprocess using the high-level asyncio subprocess APIs (https://docs.python.org/3.9/library/asyncio-subprocess.html) without getting a traceback on exit.

On exit, the attached program writes the following to stderr:

$ python3.9 kill_subprocess.py

Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x1065f0dc0>
Traceback (most recent call last):
    ...
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

If I uncomment `# process._transport.close()` or comment `asyncio.sleep(1)`, the walkback disappears. (I get the same behavior in python 3.8. I haven't tried other python versions.)

----------
components: asyncio
files: kill_subprocess.py
messages: 391349
nosy: asvetlov, rabraham, yselivanov
priority: normal
severity: normal
status: open
title: Cannot cleanly kill a subprocess using high-level asyncio APIs
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49965/kill_subprocess.py

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

From report at bugs.python.org  Mon Apr 19 04:07:46 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Apr 2021 08:07:46 +0000
Subject: [New-bugs-announce] [issue43885] ResourceWarning: unclosed
 <ssl.SSLSocket ...> test_pha_required_nocert
Message-ID: <1618819666.42.0.85346092092.issue43885@roundup.psfhosted.org>


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

bpo-35926 and fb7e7505ed1337bf40fa7b8b68317d1e86675a86 introduced code that is triggered resource errors and unhandled exceptions. It has been bothering me for a while but I could never pin point the issue. Victor's and Hai's commits 
e80697d687b6 and 73ea54620a6f seem to be related, too.

I don't understand the purpose of the test changes in fb7e7505ed1337bf40fa7b8b68317d1e86675a86. The commit looks wrong to me. Could you please take a look?
 
$ ./python -X tracemalloc=10 -m test test_ssl
0:00:00 load avg: 1.37 Run tests sequentially
0:00:00 load avg: 1.37 [1/1] test_ssl
/home/heimes/dev/python/cpython/Lib/test/support/threading_helper.py:209: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AF_INET, type=SOCK_STREAM, proto=0, laddr=('127.0.0.1', 32937), raddr=('127.0.0.1', 60292)>
  del self.thread
Object allocated at (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/threading.py", lineno 948
    self._bootstrap_inner()
  File "/home/heimes/dev/python/cpython/Lib/threading.py", lineno 990
    self.run()
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", lineno 2404
    if not self.wrap_conn():
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", lineno 2331
    self.sslconn = self.server.context.wrap_socket(
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", lineno 513
    return self.sslsocket_class._create(
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", lineno 1028
    self = cls.__new__(cls, **kwargs)

$ ./python -W "error::ResourceWarning" -m test test_ssl
0:00:00 load avg: 1.24 Run tests sequentially
0:00:00 load avg: 1.24 [1/1] test_ssl
Warning -- Unraisable exception
Exception ignored in: <ssl.SSLSocket fd=5, family=AF_INET, type=SOCK_STREAM, proto=0, laddr=('127.0.0.1', 49843), raddr=('127.0.0.1', 39420)>
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/support/threading_helper.py", line 209, in __exit__
    del self.thread
ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AF_INET, type=SOCK_STREAM, proto=0, laddr=('127.0.0.1', 49843), raddr=('127.0.0.1', 39420)>
test_ssl failed (env changed)

----------
assignee: steve.dower
components: SSL
messages: 391367
nosy: christian.heimes, shihai1991, steve.dower, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: ResourceWarning: unclosed <ssl.SSLSocket ...> test_pha_required_nocert
type: resource usage
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 19 05:06:07 2021
From: report at bugs.python.org (Federico Pellegrin)
Date: Mon, 19 Apr 2021 09:06:07 +0000
Subject: [New-bugs-announce] [issue43886] Extending/embedding Python
 documentation outdated/incomplete
Message-ID: <1618823167.79.0.105127180169.issue43886@roundup.psfhosted.org>


New submission from Federico Pellegrin <fede.evol at gmail.com>:

Hello,
We had lately some issues with various possible variants of compilation (static vs dynamic) with reference to both embedding and extending Python. There are a bunch of tickets on the topic (ie. #21536 or #34309) but I guess one important point is that the documentation seems to be not very clear on this. Also various Linux distros seem to take very different approaches (static/dynamic).

Infact from the current documentation it seems unclear if python-config should be used for both or not. We found also some references to a newer --embed flag (see ie. #36721) which is not mentioned in the documentation.
Some other sources suggest that python-config should not be used when Python is build with Py_ENABLE_SHARED=1. (ref. here: https://github.com/conda/conda-build/issues/2738#issuecomment-371148021)

Also the example looks probably outdated, as it mentions Python 3.4

It would be nice if some light would be shed on the correct practice to use and the official documentation updated.

Thanks,
Federico

----------
assignee: docs at python
components: Documentation
messages: 391370
nosy: docs at python, fede.evol
priority: normal
severity: normal
status: open
title: Extending/embedding Python documentation outdated/incomplete
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 19 07:48:23 2021
From: report at bugs.python.org (John Mish)
Date: Mon, 19 Apr 2021 11:48:23 +0000
Subject: [New-bugs-announce] [issue43887] it seems that sorted built-in
 always return floats before int if they appear to be equal
Message-ID: <1618832903.3.0.808077811631.issue43887@roundup.psfhosted.org>


New submission from John Mish <johnmish.iam at gmail.com>:

A1
>>> sorted([12.000000000000001, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 12, 12.000000000000002]
A2
>>> sorted([12.0000000000000001, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 12.0, 12]
B1
>>> sorted([11.999999999999999, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 11.999999999999998, 12]
B2
>>> sorted([11.9999999999999999, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 12.0, 12]

Hello,

In A2 and in B2 we see the same output for 2 not equal expected values.

It seems to be that floats are always first in list.

So, what about trying to "store" if some float is 12 "in limit" of 12 but from "left/-"? So then it is < than 12.

12.000000000000000000000000000001 would be then 12 but in upper limit, right/+ so > 12

What do You think?

Best regards.

PS ofc I could use decimal, but if it shouldn't work, why it does not raise exception and ask for forgiveness... ?

----------
components: Interpreter Core
messages: 391372
nosy: johnmish.iam
priority: normal
severity: normal
status: open
title: it seems that sorted built-in always return floats before int if they appear to be equal
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr 19 07:50:46 2021
From: report at bugs.python.org (Sviatoslav Sydorenko)
Date: Mon, 19 Apr 2021 11:50:46 +0000
Subject: [New-bugs-announce] [issue43888] GitHub Actions CI/CD `Coverage`
 job is broken on master
Message-ID: <1618833046.45.0.972351861197.issue43888@roundup.psfhosted.org>


New submission from Sviatoslav Sydorenko <svyatoslav at sydorenko.org.ua>:

I noticed that https://github.com/python/cpython/runs/2378199636 (a coverage job on the last commit on master at the time of writing) takes suspiciously long to complete.

I did some investigation and noticed that this job on the 3.9 branch succeeds (all of the job runs on the first page in the list are green ? https://github.com/python/cpython/actions/workflows/coverage.yml?query=branch%3A3.9)

But then I took a look at the runs on master and discovered that the last successful run was 4 months ago ? https://github.com/python/cpython/actions.html?query=is%3Asuccess+branch%3Amaster&workflow_file_name=coverage.yml.

The last success is https://github.com/python/cpython/actions/runs/444323166 and after that, starting with https://github.com/python/cpython/actions/runs/444405699, if fails consistently.

Notably, all of the failures are caused by the job timeout after *6 hours* ? GitHub platform just kills those, 6h is a default per-job timeout in GHA.

It's also important to mention that before every job starting timing out effectively burning 6 hours of GHA time for each merge and producing no useful reports, there were occasional 6h-timeouts but they weren't consistent.

Looking into the successful runs from the past, on master and other jobs, I haven't noticed it taking more than 1h35m to complete with a successful outcome. Taking into account this as a baseline, I suggest changing the timeout of the whole job or maybe just one step that actually runs coverage.

Action items:
* Set job timeout in GHA to 1h40m (allowing a bit of extra time for exceptionally slow jobs) ? this will make sure that the failure/timeout is reported sooner than 6h
* Figure out why this started happening in the first place.

I'm going to send a PR addressing the first point but feel free to pick up the investigation part ? I don't expect to have time for this anytime soon.

P.S. FTR the last timeout of this type happened two months ago ? https://github.com/python/cpython/actions.html?page=4&query=branch%3A3.9&workflow_file_name=coverage.yml.

----------
messages: 391373
nosy: webknjaz
priority: normal
severity: normal
status: open
title: GitHub Actions CI/CD `Coverage` job is broken on master
type: crash

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

From report at bugs.python.org  Mon Apr 19 11:12:15 2021
From: report at bugs.python.org (Ken Jin)
Date: Mon, 19 Apr 2021 15:12:15 +0000
Subject: [New-bugs-announce] [issue43889] Pickle performance regression in
 3.10
Message-ID: <1618845135.21.0.985662855004.issue43889@roundup.psfhosted.org>


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

Hi everyone, I noticed on speed.python.org that the pickle benchmarks are noticeably slower:

Overall, pickle slowed down by >10%
https://speed.python.org/timeline/?exe=12&base=&ben=pickle&env=1&revs=200&equid=off&quarts=on&extr=on

Pickling list and dict is also slower by >10%:
https://speed.python.org/timeline/?exe=12&base=&ben=pickle_list&env=1&revs=200&equid=off&quarts=on&extr=on

https://speed.python.org/timeline/?exe=12&base=&ben=pickle_dict&env=1&revs=200&equid=off&quarts=on&extr=on

For some reason, the pickle_pure_python benchmark which doesn't use the _pickle C library has no change.

The regression happened somewhere between commit 11159d2c9d6616497ef4cc62953a5c3cc8454afb and 3fc65b97d09fd29272fdf60d2e567bfb070da824. I don't know which commit caused it as there doesn't seem to be a change to _pickle.c. I have a weak hunch that it may be linked to Issue38530 (since the other commits in that time range are docs, sqllite3, ssl and unrelated python libraries) but I'm unsure. I'll try to bisect things this weekend if nobody's started on it by then.

Thanks for your time!

----------
components: Library (Lib)
messages: 391380
nosy: alexandre.vassalotti, kj, pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Pickle performance regression in 3.10
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr 19 14:36:19 2021
From: report at bugs.python.org (Thomas Buhrmann)
Date: Mon, 19 Apr 2021 18:36:19 +0000
Subject: [New-bugs-announce] [issue43890] Deadlock when mixing event loops
 and subprocesses
Message-ID: <1618857379.44.0.428651349576.issue43890@roundup.psfhosted.org>


New submission from Thomas Buhrmann <thomas.buehrmann at gmail.com>:

When mixing code that spawns subprocesses with code that creates event loops, Python appears to deadlock.

In the attached example, when WORKERS = 16 and ASYNC_WORKERS = 8, Python will sometimes (50% of the time?) deadlock, never exiting, with no exceptions raised. Oddly, if ASYNC_WORKERS is set to 0 or 16 (i.e., only subprocesses or only event loops), it runs reliably.

I tested this in an x86_64 Ubuntu 20.04.2 VM with Python 3.8.6. I was only able to reproduce it when the VM had more than one CPU, and I was unable to reproduce it on x86_64 MacOS.

----------
files: subprocess_asyncio_deadlock.py
messages: 391386
nosy: thomas
priority: normal
severity: normal
status: open
title: Deadlock when mixing event loops and subprocesses
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49967/subprocess_asyncio_deadlock.py

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

From report at bugs.python.org  Mon Apr 19 19:00:10 2021
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 19 Apr 2021 23:00:10 +0000
Subject: [New-bugs-announce] [issue43891] co_annotations branch caused a
 crash in stackeffect() in compile.c
Message-ID: <1618873210.06.0.38844739847.issue43891@roundup.psfhosted.org>


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

I'm working on a branch to implement PEP 649:

https://github.com/larryhastings/co_annotations/

Inada Naoki discovered a crash in that branch, discussed here, including steps to reproduce:

https://github.com/larryhastings/co_annotations/issues/10

valgrind showed me what the problem was.  stackeffect() allocates a "stack" variable, used to store pushed/popped context while iterating over the basic blocks of the function being assembled.  Most of the time, the stack is way bigger than it needs to be--we allocate 4 or 5 entries and it only uses 1 or 2.  But, somehow, in the co_annotations branch, the "stack" was occasionally *way too small*.  As in, it allocated 66 entries (!) but used 150 (!!).

I don't understand exactly how stackeffect works, so I don't know under what circumstances it would go so deep, much less what would cause it to so severely underestimate how many entries it needed.  I *did* make modifications to code generation in compile.c, so it *could* be my bug--but my changes were all much earlier in the process, and AFAIK I never touched any of the code under assemble().

Well, not until I worked around this problem, anyway.  My fix: if "stack" is too small, double the size and realloc().  Certainly it makes the problem go away.  That's checked in to my branch here:

https://github.com/larryhastings/co_annotations/commit/63b415c3607af8ba9263b179fb05bb89ccd2e036

But it doesn't address the underlying bug, whatever it is.

If anybody who understands stackeffect() could take a look and figure it out?  That would be neat-o keen.

----------
components: Interpreter Core
messages: 391413
nosy: larry
priority: normal
severity: normal
stage: patch review
status: open
title: co_annotations branch caused a crash in stackeffect() in compile.c
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 20 07:59:54 2021
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Apr 2021 11:59:54 +0000
Subject: [New-bugs-announce] [issue43892] Make match patterns explicit in
 the AST
Message-ID: <1618919994.66.0.123509458794.issue43892@roundup.psfhosted.org>


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

In the SC submission ticket for PEP 642 (https://github.com/python/steering-council/issues/43 ), Guido indicated he was in favour of the more explicit pattern matching AST changes suggested in that PEP.

This ticket covers adapting the pattern matching implementation to explicitly separate pattern nodes from expr nodes in the AST, so the code generator doesn't need to be context dependent.

----------
assignee: ncoghlan
messages: 391430
nosy: brandtbucher, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make match patterns explicit in the AST
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 20 09:03:19 2021
From: report at bugs.python.org (Jarry Shaw)
Date: Tue, 20 Apr 2021 13:03:19 +0000
Subject: [New-bugs-announce] [issue43893] typing.get_type_hints does not
 accept type annotations with leading whitespaces
Message-ID: <1618923799.18.0.0357006810909.issue43893@roundup.psfhosted.org>


New submission from Jarry Shaw <jarryshaw at icloud.com>:

`typing.get_type_hints` does not accept type annotations (in string capsulated form) with leading whitespaces.

```
>>> def foo(arg) -> ' str': ...
>>> typing.get_type_hints(foo)
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/typing.py", line 519, in __init__
    code = compile(arg, '<string>', 'eval')
  File "<string>", line 1
    str
IndentationError: unexpected indent

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/typing.py", line 1448, in get_type_hints
    value = ForwardRef(value)
  File "/usr/local/lib/python3.9/typing.py", line 521, in __init__
    raise SyntaxError(f"Forward reference must be an expression -- got {arg!r}")
SyntaxError: Forward reference must be an expression -- got ' str'
```

When elaborating on this issue, an inconsistency of hevaiour between ``eval`` function call and ``compile`` in ``'eval'`` mode was also noticed, where the former accepts leading whitespaces and the latter does not.

However, as discussed in https://bugs.python.org/issue41887 , I would then propose manually ``lstrip`` whitespaces from the type annotations:

```
519c519
<             code = compile(arg.lstrip(' \t'), '<string>', 'eval')
---
>             code = compile(arg, '<string>', 'eval')
```

----------
components: Library (Lib)
messages: 391434
nosy: jarryshaw
priority: normal
severity: normal
status: open
title: typing.get_type_hints does not accept type annotations with leading whitespaces
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 20 12:15:23 2021
From: report at bugs.python.org (E. Paine)
Date: Tue, 20 Apr 2021 16:15:23 +0000
Subject: [New-bugs-announce] [issue43894] IDLE editor file minor refactoring
Message-ID: <1618935323.45.0.384862638375.issue43894@roundup.psfhosted.org>


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

Despite being large, the PR is mostly trivial changes (e.g. changing indentation). The main changes worth noting (and hence the reason for this issue) are:
1) the renaming of `ResetColorizer` to `reset_colors`, `ResetFont` to `reset_font`, `RemoveKeybindings` to `remove_keybindings` and `ApplyKeybindings` to `apply_keybindings`.
2) removal of some potentially unneeded imports
3) renaming of the `tokeneater` args to be lowercase

I chose `reset_colors` (as proposed in PR-22682) rather than `reset_colorizer` because we are reconfiguring the Text, code context and line numbers, rather than only dealing with the colouriser.

----------
assignee: terry.reedy
components: IDLE
messages: 391449
nosy: epaine, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE editor file minor refactoring
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 20 13:00:51 2021
From: report at bugs.python.org (Ian H)
Date: Tue, 20 Apr 2021 17:00:51 +0000
Subject: [New-bugs-announce] [issue43895] Unnecessary Cache of Shared Object
 Handles
Message-ID: <1618938051.55.0.304648722652.issue43895@roundup.psfhosted.org>


New submission from Ian H <insertinterestingnamehere at gmail.com>:

While working on another project I noticed that there's a cache of shared object handles kept inside _PyImport_FindSharedFuncptr. See https://github.com/python/cpython/blob/b2b6cd00c6329426fc3b34700f2e22155b44168c/Python/dynload_shlib.c#L51-L55. It appears to be an optimization to work around poor caching of shared object handles in old libc implementations. After some testing, I have been unable to find any meaningful performance difference from this cache, so I propose we remove it to save the space.

My initial tests were on Linux (Ubuntu 18.04). I saw no discernible difference in the time for running the Python test suite with a single thread. Running the test suite using a single thread shows a lot of variance, but after running with and without the cache 40 times the mean times with/without the cache was nearly the same. Interpreter startup time also appears to be unaffected. This was all with a debug build, so I'm in the process of collecting data with a release build to see if that changes anything.

----------
messages: 391453
nosy: Ian.H
priority: normal
severity: normal
status: open
title: Unnecessary Cache of Shared Object Handles
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 20 13:48:52 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 20 Apr 2021 17:48:52 +0000
Subject: [New-bugs-announce] [issue43896] Update the Sphinx directive for
 super from function to class
Message-ID: <1618940932.03.0.571461842576.issue43896@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

This PR updates the page [*Built-in Functions*](https://docs.python.org/3.9/library/functions.html#super) of the Python library documentation: `super` is not a `function` (`isinstance(super, type(lambda: None))` is `False`), it is a `type` (`isinstance(super, type)` is `True`), like `int`, `tuple`, `set`, etc. So it should get the same ?class? prefix, i.e.

> **super**([*type*[, *object-or-type*]])

should become

> *class* **super**([*type*[, *object-or-type*]])

----------
assignee: docs at python
components: Documentation
messages: 391458
nosy: docs at python, maggyero
priority: normal
severity: normal
status: open
title: Update the Sphinx directive for super from function to class
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 20 15:35:33 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 20 Apr 2021 19:35:33 +0000
Subject: [New-bugs-announce] [issue43897] Implement support for validation
 of pattern matching ASTs
Message-ID: <1618947333.54.0.307745509696.issue43897@roundup.psfhosted.org>


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

ASTs of case clauses for PEP 636 are not validated through PyAST_Validate right now, which might crash the Python interpreter when compiling some trees that doesn't hold the assumptions of the compiler.

----------
assignee: BTaskaya
messages: 391469
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Implement support for validation of pattern matching ASTs
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 20 15:59:28 2021
From: report at bugs.python.org (Ellis trisk-grove)
Date: Tue, 20 Apr 2021 19:59:28 +0000
Subject: [New-bugs-announce] [issue43898] Python fails to import .dylib but
 works when extension is changed to .so
Message-ID: <1618948768.32.0.880323883479.issue43898@roundup.psfhosted.org>


New submission from Ellis trisk-grove <etriskgrove at gmail.com>:

This issue is pretty much summed up by the title. Python does manage to import the library and use it however only when the extension is .so otherwise python cannot find it and fails to import.

----------
components: macOS
messages: 391473
nosy: etriskgrove, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python fails to import .dylib but works when extension is changed to .so
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 20 17:47:05 2021
From: report at bugs.python.org (David Alvarez Lombardi)
Date: Tue, 20 Apr 2021 21:47:05 +0000
Subject: [New-bugs-announce] [issue43899] separate builtin function
Message-ID: <1618955225.8.0.321357369426.issue43899@roundup.psfhosted.org>


New submission from David Alvarez Lombardi <alvarezdqal at gmail.com>:

I frequently find myself doing the following for lists, sets, and dicts.

````
passes = [x for x in seq if cond(x)]
fails = [x for x in seq if not cond(x)]
````

The proposed function would behave similarly to `filter`, but it would return a tuple of the passes iterable and fails iterable rather than just the passes.

````
my_list = [-3, -2, -1, 0, 1, 2, 3]
def is_positive(n):
    return n > 0

positives, negatives = separate(function=is_positive, iterable=my_list)
````

----------
messages: 391479
nosy: alvarezdqal
priority: normal
severity: normal
status: open
title: separate builtin function
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 20 17:55:08 2021
From: report at bugs.python.org (David Alvarez Lombardi)
Date: Tue, 20 Apr 2021 21:55:08 +0000
Subject: [New-bugs-announce] [issue43900] string comprehension
Message-ID: <1618955708.38.0.581362261608.issue43900@roundup.psfhosted.org>


New submission from David Alvarez Lombardi <alvarezdqal at gmail.com>:

As of now the best way to filter a str is to convert to list, filter, then join back to a str. I think a a string comprehension would be very useful for this.


So to get only ascii_lower case chars given this string,
````
s = "a1b2c3d4"
````

I could do this
````
filtered_s = c"ch for ch in s if ch in string.ascii_lowercase"
````

instead of this.
````
s_list = []
for i in range(len(s)):
    if s[i] in string.ascii_lowercase:
        s_list.append(s[i])

filtered_s = "".join(s_list)
````

----------
messages: 391480
nosy: alvarezdqal
priority: normal
severity: normal
status: open
title: string comprehension
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 21 02:44:01 2021
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 21 Apr 2021 06:44:01 +0000
Subject: [New-bugs-announce] [issue43901] Add an empty annotations dict to
 all classes and modules
Message-ID: <1618987441.84.0.207444160908.issue43901@roundup.psfhosted.org>


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

The behavior of the __annotations__ member is wildly different between the three objects (function, class, module) that support it.  Many of these differences are minor, but one in particular has been an awful wart for years: classes can inherit __annotations__ from their base classes.  This is incontestably a misfire of the original design--it is never useful, it is only confusing, and libraries who examine annotations have had to work around it for years.

I started a thread in January 2021 in which I brought up this and other inconsistencies with respect to __annotations_:

    https://mail.python.org/archives/list/python-dev at python.org/thread/AWKVI3NRCHKPIDPCJYGVLW4HBYTEOQYL/

The reaction was positive: yes, that's a genuine problem, and there's an easy, highly compatible fix that everybody liked: classes should always have an __annotations__ dict set.  So that the behavior is consistent, modules should always have one set too.

This won't be a large change.  However, there are a lot of changes flying around with respect to __annotations__ right now.  My plan is to get the work ready, then when the dust is mostly-settled I'll get it updated, reviewed, and merged.  Definitely before Python 3.10b1.

Long term, I'd like to get the other changes to annotations I proposed in that thread:
  * del o.__annotations__ always raises an exception.
  * o.__annotations__ is permitted to be None.
  * You can only set o.__annotations__ to either a dict or None.
But it's probably best to not change everything all at once.

----------
components: Interpreter Core
messages: 391490
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Add an empty annotations dict to all classes and modules
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 21 03:59:53 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Apr 2021 07:59:53 +0000
Subject: [New-bugs-announce] [issue43902] ssl module: add getter for
 SSL_CTX* and SSL*
Message-ID: <1618991993.39.0.313806581209.issue43902@roundup.psfhosted.org>


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

Python's ssl module exposes a limited and opinionated set of knobs to tune OpenSSL's behavior. Each new setter, getter, or function must be carefully design, tested, and documented. For each feature OpenSSL's C API must be converted into a Pythonic, self-explanatory interface.

I would like to give experts and power users an interface to set advanced options. libffi-based solutions like ctypes and cffi are obvious choices. For libffi to work, users need to be able to get the address of ssl.SSLContext()'s SSL_CTX pointer and the SSL* pointer of the internal _SSLSocket object.

While it's possible to use pointer arithmetic with id(ctx) + offset, I would like to add a more convenient way. Pointer arithmetic with ctypes is non-trivial. Users would have to rely on internal, private layout of PySSLContext and PySSLSocket struct. I'm considering two new methods ctx._ssl_ctx_addr and ssl._ssl_addr (names are tentative).

>>> import ssl, ctypes
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
>>> libssl = ctypes.CDLL("libssl.so.1.1")  # ssl._ssl.__file__ works, too
>>> libssl.SSL_CTX_set_ciphersuites(ctx._ssl_ctx_addr(), b"TLS_CHACHA20_POLY1305_SHA256")
1

Steve, Nathaniel, how do you like the idea in general? Do you have better ideas for function names?

----------
assignee: christian.heimes
components: SSL
messages: 391498
nosy: christian.heimes, njs, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: ssl module: add getter for SSL_CTX* and SSL*
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Apr 21 04:15:02 2021
From: report at bugs.python.org (Olli)
Date: Wed, 21 Apr 2021 08:15:02 +0000
Subject: [New-bugs-announce] [issue43903] round() produces incorrect results
 with certain values
Message-ID: <1618992902.95.0.267811041395.issue43903@roundup.psfhosted.org>


New submission from Olli <mrblueskies69 at gmail.com>:

When rounding numbers with round(), middle values at with even base number are rounded in wrong direction.

Python 3.9.1 (default, Feb  3 2021, 07:38:02) 
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin

MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports)
macOS 11.2.3 (20D91), Darwin 20.3.0

to reproduce (wrong results marked with "*"):

floats:

>>> for i in range(0, 10):
...     i /= 2
...     print(i, '->', round(i))
... 
0.0 -> 0
0.5 -> 0 *
1.0 -> 1
1.5 -> 2
2.0 -> 2
2.5 -> 2 *
3.0 -> 3
3.5 -> 4
4.0 -> 4
4.5 -> 4 *

and for ints:

>>> for i in range(50, 1000, 50):
...     print(i, '->', round(int(i), -2))
... 
50 -> 0 *
100 -> 100
150 -> 200
200 -> 200
250 -> 200 *
300 -> 300
350 -> 400
400 -> 400
450 -> 400 *
500 -> 500
550 -> 600
600 -> 600
650 -> 600 *
700 -> 700
750 -> 800
800 -> 800
850 -> 800 *
900 -> 900
950 -> 1000

----------
components: Library (Lib)
messages: 391499
nosy: MrBlueSkies
priority: normal
severity: normal
status: open
title: round() produces incorrect results with certain values
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 21 04:54:18 2021
From: report at bugs.python.org (berkbayr)
Date: Wed, 21 Apr 2021 08:54:18 +0000
Subject: [New-bugs-announce] [issue43904] Documentation for argparse,
 missed opportunity
Message-ID: <1618995258.21.0.414286523788.issue43904@roundup.psfhosted.org>


New submission from berkbayr <berkbayraktar at gmail.com>:

In the API reference page for argparse, the following example is used for formatter_class:

...     formatter_class=argparse.RawDescriptionHelpFormatter,
...     description=textwrap.dedent('''\
...         Please do not mess up this text!
...         --------------------------------
...             I have indented it
...             exactly the way
...             I want it
...         '''))

I propose the example would be vastly improved by the following change:

...         Please do not mess up this text!
...         --------------------------------
...             I have indented it
...             exactly the way
...             I intended 
...         '''))

----------
assignee: docs at python
components: Documentation
messages: 391501
nosy: berkbayraktar, docs at python
priority: normal
severity: normal
status: open
title: Documentation for argparse, missed opportunity
type: enhancement

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

From report at bugs.python.org  Wed Apr 21 08:19:17 2021
From: report at bugs.python.org (Erik Carstensen)
Date: Wed, 21 Apr 2021 12:19:17 +0000
Subject: [New-bugs-announce] [issue43905] dataclasses.astuple does deepcopy
 on all fields
Message-ID: <1619007557.11.0.871267775065.issue43905@roundup.psfhosted.org>


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

It seems that the 'dataclass.astuple' function does a deepcopy of all fields. This is not documented. Two problems:

1. Dictionary keys that rely on object identity are ruined:
    import dataclasses
    @dataclasses.dataclass
    class Foo:
        key: object
    key = object()
    lut = {key: 5}
    (y,) = dataclasses.astuple(Foo(x))
    # KeyError
    lut[y]

2. dataclasses can only be converted to a tuple if all fields are serializable:

    import dataclasses
    @dataclasses.dataclass
    class Foo:
        f: object
    foo = Foo(open('test.py'))
    dataclasses.astuple(foo)

->

TypeError: cannot pickle '_io.TextIOWrapper' object


In my use case, I just want a list of all fields. I can do the following as a workaround:
  (getattr(foo, field.name) for field in dataclasses.fields(foo))

Tested on Python 3.8.7 and 3.7.9.

----------
components: Library (Lib)
messages: 391516
nosy: mandolaerik
priority: normal
severity: normal
status: open
title: dataclasses.astuple does deepcopy on all fields
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Apr 21 12:49:30 2021
From: report at bugs.python.org (=?utf-8?b?0LrQvtGE0LXRkdC6?=)
Date: Wed, 21 Apr 2021 16:49:30 +0000
Subject: [New-bugs-announce] [issue43906] turtle graphics don't work
Message-ID: <1619023770.04.0.6173882524.issue43906@roundup.psfhosted.org>


Change by ?????? <antiendershow221 at gmail.com>:


----------
components: Build
files: Screenshot_16.png
nosy: antiendershow221
priority: normal
severity: normal
status: open
title: turtle graphics don't work
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49969/Screenshot_16.png

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

From report at bugs.python.org  Wed Apr 21 14:08:15 2021
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Wed, 21 Apr 2021 18:08:15 +0000
Subject: [New-bugs-announce] [issue43907] pickle.py bytearray memoization
 bug with protocol 5
Message-ID: <1619028495.22.0.0031927289703.issue43907@roundup.psfhosted.org>


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

The new codepath for the BYTEARRAY8 bytecode is missing memoization:

>>> import pickletools, pickle
>>> b = (bytearray(b"abc"), ) * 2
>>> b1, b2 = pickle.loads(pickle.dumps(b, 5)) # C version
>>> b1 is b2
True
(bytearray(b'abc'), bytearray(b'abc'))
>>> b1, b2 = pickle.loads(pickle._dumps(b, 5)) # python version
>>> b1 is b2 # :-(
False

Found it because PyPy is using pickle.py with no C implementation. I'm preparing a patch.

----------
messages: 391537
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: pickle.py bytearray memoization bug with protocol 5

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

From report at bugs.python.org  Wed Apr 21 14:52:19 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Apr 2021 18:52:19 +0000
Subject: [New-bugs-announce] [issue43908] array.array should remain immutable
Message-ID: <1619031139.87.0.55032170532.issue43908@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

Hi Victor,

Sorry for making this a deferred blocker. I recall that we had a brief discussion somewhere about an accidental change to the array.array type -- this is now a heap type (Py_TPFLAGS_HEAPTYPE is set), and as a consequence it is no longer immutable.

In 3.9 this is an error:

>>> import array        
>>> array.array.foo = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'array.array'
>>>

But in 3.10a7 it passes:

>>> array.array.foo = 1
>>> array.array.foo    
1
>>>

I would like this type (and other types that have been or will be converted to heap types) to remain immutable. How can we do that? I think we may need a new flag bit meaning "built-in type, immutable". This bit should not be inherited of course.

What do you think? (Feel free to close if this is a duplicate -- I couldn't find where we discussed this previously, sorry.)

----------
assignee: vstinner
messages: 391540
nosy: gvanrossum, vstinner
priority: deferred blocker
severity: normal
status: open
title: array.array should remain immutable
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Apr 22 00:29:23 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 22 Apr 2021 04:29:23 +0000
Subject: [New-bugs-announce] [issue43909] Fuzz dis module and find crashes
 for dis.dis(), dis.get_instructions() dis.show_code()
Message-ID: <1619065763.61.0.475663843227.issue43909@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

We write a fuzz tool to fuzz Python standard libraries, and find three crashes: dis.dis(),  dis.get_instructions() dis.show_code() in dis module. 


dis.dis()
==========================================
xiaxinmeng:~ xiaxinmeng$ python3.10
Python 3.10.0a3 (v3.10.0a3:8bae2a958e, Dec  7 2020, 15:31:51) 
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> dis.dis("s%-yPdrns"*1000000)
Segmentation fault: 11
=================================================


dis.get_instructions()
=================================================
Python 3.10.0a3 (v3.10.0a3:8bae2a958e, Dec  7 2020, 15:31:51) 
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> dis.get_instructions("c/f/x"*1000000)
Segmentation fault: 11
==================================================


dis.show_code()
===================================================
Python 3.10.0a3 (v3.10.0a3:8bae2a958e, Dec  7 2020, 15:31:51) 
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> dis.show_code("G/7/K"*1000000)
Segmentation fault: 11
====================================================

----------
components: Library (Lib)
messages: 391574
nosy: xxm
priority: normal
severity: normal
status: open
title: Fuzz dis module and find crashes for dis.dis(),  dis.get_instructions() dis.show_code()
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 22 04:03:45 2021
From: report at bugs.python.org (Mark Gordon)
Date: Thu, 22 Apr 2021 08:03:45 +0000
Subject: [New-bugs-announce] [issue43910] cgi.parse_header does not handle
 escaping correctly
Message-ID: <1619078625.68.0.392663181082.issue43910@roundup.psfhosted.org>


New submission from Mark Gordon <msg555 at gmail.com>:

cgi.parse_header incorrectly handles unescaping of quoted-strings

Note that you can find the related RFCs to how HTTP encodes the Content-Type header at https://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html and further discussion on how quoted-string is defined at https://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-16.html#rfc.section.3.2.1.p.3.

The way parse_header is written it has no context to be able to tell if a backslash is escaping a double quote or if the backslash is actually the escaped character and the double quote is free-standing, unescaped. For this reason it fails to parse values that have a backslash literal at the end. e.g. the following Content-Type will fail to be parsed

a/b; foo="moo\\"; bar=baz

Example run on current cpython master demonstrating the bug:

Python 3.10.0a7+ (heads/master:660592f67c, Apr 21 2021, 22:51:04) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi
>>> query = 'a; foo="moo\\\\"; bar=cow' 
>>> print(query)
a; foo="moo\\"; bar=cow
>>> cgi.parse_header(query)
('a', {'foo': '"moo\\\\"; bar=cow'})

----------
components: Library (Lib)
messages: 391580
nosy: msg555
priority: normal
severity: normal
status: open
title: cgi.parse_header does not handle escaping correctly
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 22 05:13:22 2021
From: report at bugs.python.org (Jens)
Date: Thu, 22 Apr 2021 09:13:22 +0000
Subject: [New-bugs-announce] [issue43911] Queue.get() memory leak
Message-ID: <1619082802.82.0.467723490819.issue43911@roundup.psfhosted.org>


New submission from Jens <multiks2200 at gmail.com>:

I use the following code to produce what looks like a memory leak after emptying a queue with the get() method.


    import queue
    import os
    import psutil
    
    def run(del_after_puts, del_after_gets, n_puts, process):
    
            mem = queue.Queue()
        
            for msg in range(n_puts):
                msg_put = f'{msg}_0000000000000000000000000000000000000000000000000000000000000333333333333331111111111'
                if msg % 1000000 == 0:
                    print(f'puting  {msg} qsize {len(mem.queue)}')
                mem.put(msg_put)
        
        
            print(f'------ put done  ----- qsize {len(mem.queue)}')
            print(f'mem_pct {round(process.memory_percent(), 2)}% ')
        
            if del_after_puts:
                print(f'deleting queue after puts {mem}')
                del mem
                print(f'mem_pct {round(process.memory_percent(), 2)}% ')
                return
        
            for _ in range(n_puts):
                msg_get = mem.get()
                msg = int(msg_get.split('_')[0])
                if msg % 1000000 == 0:
                    print(f'getting_q {msg} qsize {len(mem.queue)} ')
                    mem.task_done()
                
            print(f'------ gets done  ----- qsize {len(mem.queue)}')
            print(f'mem_pct {round(process.memory_percent(), 2)}% ')
        
            if del_after_gets:
                print(f'deleting queue after gets {mem}')
                del mem
                print(f'mem_pct {round(process.memory_percent(), 2)}% ')
                return
        
        if __name__ == '__main__':
            del_after_puts = False
            del_after_gets = False
            n_puts = 20_000_000
            print()
            print('#########')
            print(f'del_after_puts {del_after_puts} del_after_gets {del_after_gets} n_puts {n_puts}')
        
            process = psutil.Process(os.getpid())
            print('before run')
            print(f'mem_pct {round(process.memory_percent(), 2)}% ')
        
            run(del_after_puts, del_after_gets, n_puts, process)
        
            print(f'after run return')
            print(f'mem_pct {round(process.memory_percent(), 2)}% ')

This script can be run in 3 ways:
1. Add n_puts elements into the queue and then empty it.
2. Add n_puts elements into the queue and then delete the queue object
3. Add n_puts elements into the queue and then empty it and then delete the queue object.

For the 1st and 3rd case, the script seems to produce a memory leak as in the following:

1st case, before putting elements into the queue mem used is 0.15%, after emptying it  2.22%:

> #########
> 
> del_after_puts False del_after_gets False n_puts 20000000
> 
> before run
> 
> mem_pct 0.15% 
> 
> ------ put done  ----- qsize 20000000
> 
> mem_pct 37.61% 
> 
> ------ gets done  ----- qsize 0
> 
> mem_pct 2.22%

3rd case, before putting elements into the queue mem used is 0.15%, after emptying it  2.22%, after deleting the object, 2.22%:

> #########
> 
> del_after_puts False del_after_gets True n_puts 20000000
> 
> before run
> 
> mem_pct 0.15% 
> 
> ------ put done  ----- qsize 20000000
> 
> mem_pct 37.61% 
> 
> ------ gets done  ----- qsize 0
> 
> mem_pct 2.22%
> 
> deleting queue after gets <queue.Queue object at 0x7fbd87295a10>
> 
> mem_pct 2.22%

For the 2nd case, mem_pct at the start is 0.15%, after putting all elements into the queue and just deleting it, 0.16%, which is almost the same.

> #########
> 
> del_after_puts True del_after_gets False n_puts 20000000
> 
> before run
> 
> mem_pct 0.15% 
> 
> ------ put done  ----- qsize 20000000
> 
> mem_pct 37.61% 
> 
> deleting queue after puts <queue.Queue object at 0x7f29084eca10>
> 
> mem_pct 0.16%

As it can be seen, memory returns to the start level only in the first case when only `queue.put()` is invoked, hence it seems that `queue.get()` produces a memory leak. 

This is persistent across python 3.7, 3.8, as well as 3.9.

----------
messages: 391586
nosy: multiks2200
priority: normal
severity: normal
status: open
title: Queue.get() memory leak
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 22 10:02:51 2021
From: report at bugs.python.org (Andy Maier)
Date: Thu, 22 Apr 2021 14:02:51 +0000
Subject: [New-bugs-announce] [issue43912] http.client.BadStatusLine raised
 and response contains request
Message-ID: <1619100171.95.0.666024363299.issue43912@roundup.psfhosted.org>


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

Hello, we have a nasty occurrence of BadStatusLine that shows the status line of the request(!!) in one of our projects. That exception is raised when checking a response and should check the response, not the request. 

Further debugging revealed that not only the status line is from the request, but also the headers and the body of the response are from the request when this error happens.

Example exception when using http.client to send the requests:

    http.client.BadStatusLine: POST http://localhost:50000 HTTP/1.1

I have created a standalone script that can be used to reproduce the behavior. The script can use http.client or the requests package for sending the requests. The server is a threaded HTTP server.

The script needs to be run multiple times to reproduce the error. On my local system, the error showed up pretty reliably within the first 50 repetitions of the script.

The header comment of the script explains the details.

If http.client is chosen to be used, the script is purely based on standard Python library functions. The error shows up on all CPython versions I tried, up to 3.9.

----------
components: Library (Lib)
files: badstatusline.py
messages: 391601
nosy: andymaier
priority: normal
severity: normal
status: open
title: http.client.BadStatusLine raised and response contains request
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49971/badstatusline.py

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

From report at bugs.python.org  Thu Apr 22 13:30:03 2021
From: report at bugs.python.org (Ryan Tarpine)
Date: Thu, 22 Apr 2021 17:30:03 +0000
Subject: [New-bugs-announce] [issue43913] unittest module cleanup functions
 not run unless tearDownModule() is defined
Message-ID: <1619112603.21.0.888509270435.issue43913@roundup.psfhosted.org>


New submission from Ryan Tarpine <rtarpine at google.com>:

Functions registered with unittest.addModuleCleanup are not called unless the user defines tearDownModule in their test module.

This behavior is unexpected because functions registered with TestCase.addClassCleanup are called even the user doesn't define tearDownClass, and similarly with addCleanup/tearDown.

The implementing code is basically the same for all 3 cases, the difference is that unittest.TestCase itself defines tearDown and tearDownClass; so even though doClassCleanups is only called if tearDownClass is defined, in practice it always is.

doModuleCleanups should be called even if tearDownModule is not defined.

----------
components: Library (Lib)
messages: 391619
nosy: rtarpine
priority: normal
severity: normal
status: open
title: unittest module cleanup functions not run unless tearDownModule() is defined
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Apr 22 14:08:10 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 22 Apr 2021 18:08:10 +0000
Subject: [New-bugs-announce] [issue43914] Highlight invalid ranges in
 SyntaxErrors
Message-ID: <1619114890.78.0.876060892584.issue43914@roundup.psfhosted.org>


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

To improve the user experience understanding what part of the error messages associated to SyntaxErrors are wrong, we can highlight the whole error range and not only place the caret at the first character. In this way:

>>> foo(x, z for z in range(10), t, w)
  File "<stdin>", line 1
    foo(x, z for z in range(10), t, w)
           ^
SyntaxError: Generator expression must be parenthesized

becomes

>>> foo(x, z for z in range(10), t, w)
  File "<stdin>", line 1
    foo(x, z for z in range(10), t, w)
           ^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized

----------
messages: 391620
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Highlight invalid ranges in SyntaxErrors

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

From report at bugs.python.org  Thu Apr 22 15:04:40 2021
From: report at bugs.python.org (Steve Dower)
Date: Thu, 22 Apr 2021 19:04:40 +0000
Subject: [New-bugs-announce] [issue43915] Add PCbuild/blurb.bat
Message-ID: <1619118280.75.0.975256494991.issue43915@roundup.psfhosted.org>


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

I'm sick of writing long commands to invoke blurb, so add a batch file to do it.

----------
assignee: steve.dower
components: Build, Windows
messages: 391623
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add PCbuild/blurb.bat
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 22 17:31:58 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 22 Apr 2021 21:31:58 +0000
Subject: [New-bugs-announce] [issue43916] Check that new heap types cannot
 be created uninitialised
Message-ID: <1619127118.97.0.615486795072.issue43916@roundup.psfhosted.org>


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

I'm creating this issue and marking it as a deferred blocker to make sure we don't forget to check this (adding tests) before the release.

Check this message from Serhiy regarding heap typed concerns:

https://bugs.python.org/msg391598

----------
messages: 391634
nosy: pablogsal, serhiy.storchaka, vstinner
priority: deferred blocker
severity: normal
status: open
title: Check that new heap types cannot be created uninitialised
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 22 18:46:38 2021
From: report at bugs.python.org (Egor)
Date: Thu, 22 Apr 2021 22:46:38 +0000
Subject: [New-bugs-announce] [issue43917] An error in classmethod example in
 the documentation of descriptor
Message-ID: <1619131598.14.0.103943523706.issue43917@roundup.psfhosted.org>


New submission from Egor <pixel.egor at gmail.com>:

In this section https://docs.python.org/3/howto/descriptor.html#class-methods in the example of python implementation of ClassMethod inside __get__ method I think that we should check hasattr(self.f, "__get__") instead of hasattr(obj, "__get__").

----------
assignee: docs at python
components: Documentation
messages: 391638
nosy: docs at python, rhettinger, titanolodon
priority: normal
severity: normal
status: open
title: An error in classmethod example in the documentation of descriptor
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 22 23:30:06 2021
From: report at bugs.python.org (Erik Welch)
Date: Fri, 23 Apr 2021 03:30:06 +0000
Subject: [New-bugs-announce] [issue43918] anext builtin docstring has no
 signature text or info about default argument
Message-ID: <1619148606.41.0.129428714687.issue43918@roundup.psfhosted.org>


New submission from Erik Welch <erik.n.welch at gmail.com>:

The new builtin `anext` does not have a signature (from `inspect.signature(anext)`).  This is expected, because `inspect` does not yet support signatures with C NULL default value.  However, `anext` also doesn't have text in its docstring that describes its signature as is typical for builtins.  This means `help(anext)` in the Python REPL gives no indication how to call the function.  It should.

This is clearly an oversight.  See comment here: https://github.com/python/cpython/pull/23847#commitcomment-45318696

Also, the "default" argument is not described in the docstring.

Related issue: https://bugs.python.org/issue31861

(PR forthcoming)

----------
components: Interpreter Core
messages: 391650
nosy: eriknw, pablogsal
priority: normal
severity: normal
status: open
title: anext builtin docstring has no signature text or info about default argument
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 23 02:27:47 2021
From: report at bugs.python.org (edgj4718)
Date: Fri, 23 Apr 2021 06:27:47 +0000
Subject: [New-bugs-announce] [issue43919] Potential bug in the "request"
 package.
Message-ID: <1619159267.63.0.974142045431.issue43919@roundup.psfhosted.org>


New submission from edgj4718 <edmondgjeloshi28 at gmail.com>:

Hello there,

I am creating a client application with python. This application consists in extracting some data from an API and doing something with it. Anyway, I added a space in the end of the URL where I am supposed to have the data, and the API did not send any data as it probably the new URL with the added space was the issue. I think this is a bug and the URL should be checked from any possible empty strings, especially in the end and in the start of the URL.

----------
components: Extension Modules
files: bug.PNG
messages: 391658
nosy: edgj4718
priority: normal
severity: normal
status: open
title: Potential bug in the "request" package.
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49972/bug.PNG

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

From report at bugs.python.org  Fri Apr 23 05:52:47 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 23 Apr 2021 09:52:47 +0000
Subject: [New-bugs-announce] [issue43920] OpenSSL 3.0.0: handle empty cadata
 consistently
Message-ID: <1619171567.45.0.941398900473.issue43920@roundup.psfhosted.org>


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

OpenSSL 3.0.0-alpha15 handles empty data input to d2i_X509_bio() and PEM_read_bio_X509() differently. This causes cadata test for invalid data to fail with inconsistent error message.

Let's handle 0 result case more consistent and raise an error message that is more understandable than "no start line" or "not enough data".

----------
assignee: christian.heimes
components: SSL
messages: 391673
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: OpenSSL 3.0.0: handle empty cadata consistently
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/issue43920>
_______________________________________

From report at bugs.python.org  Fri Apr 23 06:56:18 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 23 Apr 2021 10:56:18 +0000
Subject: [New-bugs-announce] [issue43921] test_ssl fails on Windows buildbots
Message-ID: <1619175378.51.0.235353622205.issue43921@roundup.psfhosted.org>


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

https://buildbot.python.org/all/#/builders/405/builds/9

Extract from the logs:

The Buildbot has detected a new failure on builder AMD64 Windows8.1 Non-Debug 3.x while building python/cpython.
Full details are available at:
    https://buildbot.python.org/all/#builders/405/builds/9

Buildbot URL: https://buildbot.python.org/all/

Worker for this Build: ware-win81-release

Build Reason: <unknown>
Blamelist: E-Paine <63801254+E-Paine at users.noreply.github.com>, Raymond Hettinger <rhettinger at users.noreply.github.com>, Simon Charette <charette.s at gmail.com>, Steve Dower <steve.dower at python.org>

BUILD FAILED: failed test (failure)


Summary of the results of the build (if available):
===================================================

== Tests result: FAILURE then FAILURE ==

395 tests OK.

10 slowest tests:
- test_multiprocessing_spawn: 2 min 43 sec
- test_concurrent_futures: 2 min 25 sec
- test_io: 1 min 43 sec
- test_largefile: 1 min 41 sec
- test_peg_generator: 1 min 39 sec
- test_mmap: 1 min 19 sec
- test_asyncio: 58.8 sec
- test_regrtest: 45.3 sec
- test_unparse: 44.1 sec
- test_tokenize: 41.1 sec

1 test failed:
    test_ssl

30 tests skipped:
    test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll
    test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue
    test_multiprocessing_fork test_multiprocessing_forkserver test_nis
    test_openpty test_ossaudiodev test_pipes test_poll test_posix
    test_pty test_pwd test_readline test_resource test_spwd
    test_syslog test_threadsignals test_wait3 test_wait4
    test_xxtestfuzz test_zipfile64

1 re-run test:
    test_ssl

Total duration: 9 min 15 sec



Captured traceback
==================

Traceback (most recent call last):
   File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ssl.py", line 2333, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\ssl.py", line 1070, in _create
    self.do_handshake()
   File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:969)


Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ssl.py", line 255, in wrapper
    return func(*args, **kw)
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ssl.py", line 3171, in test_wrong_cert_tls13
    self.fail("Use of invalid cert should have failed!")
AssertionError: Use of invalid cert should have failed!



Test report
===========

Failed tests:

- test_ssl

Failed subtests:

- test_wrong_cert_tls13 - test.test_ssl.ThreadedTests




Sincerely,
 -The Buildbot

----------
assignee: christian.heimes
messages: 391677
nosy: christian.heimes, pablogsal
priority: normal
severity: normal
status: open
title: test_ssl fails on Windows buildbots
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 23 10:36:50 2021
From: report at bugs.python.org (Julien Castiaux)
Date: Fri, 23 Apr 2021 14:36:50 +0000
Subject: [New-bugs-announce] [issue43922] Double dots in quopri transported
 emails
Message-ID: <1619188610.43.0.088106557205.issue43922@roundup.psfhosted.org>


New submission from Julien Castiaux <julien.castiaux at gmail.com>:

Hello,

We received multiple bug reports about broken links in rich html emails. Sometime, in some emails, a link like <a href="https://example.com"> would become <a href="https://example..com>, notice the double dot.

After multiple researches both in the Python email source code and in the RFC, it turns out that Python correctly implements the standard but that the distant (non-python) smtp server used by some of our customers doesn't.

The various email standard state the following:

1) As a single dot (".", chr(0x2e)) in a line ends the SMTP transmission, such single dots must be escaped when they are part of the message. RFC 5321, section 4.5.2 requires to escape all dots when they appear at the beginning of a line, using a dot as escape symbol. That is, when the user message contains: "\r\n.\r\n", it is escaped to "\r\n..\r\n". The other smtp side is responsible to remove the extra dot.

2) When we transport the email body using the quoted-printable encoding, RFC 2045 requires each line to have maximum 78 characters and define a single equal ("=", chr(0x3d)) as soft-warp sequence to fold lines too long. The RFC does only require to split the line outside of a quoted character (cannot split in the middle of "=2E"). Like any other character, it is allowed to split the line before a dot.

Take the following example:

    from email.message import EmailMessage
    from email.policy import SMTP

    msg = EmailMessage(policy=SMTP)
    msg.set_context("Hello there, just need some text to reach that seventy-six character, example.com")
    #                                                                                             ^
    #                                                                                         78th char

    print(msg.as_string())
    # Content-Type: text/plain; charset="utf-8"
    # Content-Transfer-Encoding: quoted-printable
    # MIME-Version: 1.0
    #
    # Hello there, just need some text to reach that seventy-six character, example=
    # .com

When the message is sent over smtp, smtplib escapes the line ".com" to become "..com" as required by the RFC. So no problem in the python implementation, it is the other side that is buggy.

But! We have two solutions to "fix" the other side, the problem is that they do not correctly parse lines starting with a dot. A solution would be to ensure no line starts with the dot character. Two solutions : (1) quoted-printable encode dots when they are at the beginning of a line, (2) prevent the line folding code from splitting a line before a dot.

(1) is allowed by the RFC, any character can be quoted-printable encoded even those that have a safe ascii representation already. In our "example=\n.com" example above, we can qp the code: "example=\n=2Ecom". The line starts with a "2" instead of a dot and the content is the same.

(2) is allowed by the RFC, the RFC only states that a line must be at most 78 chars long, it also states it is allowed to fold a line anywhere but in a quoted-printable sequence. It is safe to split a line earlier than the 78th character. In our "example=\n.com" example above, we could split the line at the 77th character: "exampl=\ne.com". The line starts with a "e" instead of a dot and the content is the same.

A pull request is coming shortly.

----------
components: email
messages: 391698
nosy: Julien Castiaux, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Double dots in quopri transported emails
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Apr 23 12:22:56 2021
From: report at bugs.python.org (FHTMitchell)
Date: Fri, 23 Apr 2021 16:22:56 +0000
Subject: [New-bugs-announce] [issue43923] Can't create generic NamedTuple as
 of py3.9
Message-ID: <1619194976.58.0.205362589455.issue43923@roundup.psfhosted.org>


New submission from FHTMitchell <fhtmitchell at gmail.com>:

As of python 3.9, you now can't have multiple inheritance with `typing.NamedTuple` subclasses. This seems sensible, until you realise that `typing.Generic` works via inheritance. This fails whether or not `from __future__ import annotations` is enabled.

example:

```
class Group(NamedTuple, Generic[T]):
     key: T
     group: List[T]
 
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-fc238c4826d7> in <module>
----> 1 class Group(NamedTuple, Generic[T]):
      2     key: T
      3     group: List[T]
      4 

~/.conda/envs/py39/lib/python3.9/typing.py in _namedtuple_mro_entries(bases)
   1818 def _namedtuple_mro_entries(bases):
   1819     if len(bases) > 1:
-> 1820         raise TypeError("Multiple inheritance with NamedTuple is not supported")
   1821     assert bases[0] is NamedTuple
   1822     return (_NamedTuple,)

TypeError: Multiple inheritance with NamedTuple is not supported
```

This worked fine in python 3.7 and 3.8 and as I understand it was one of the motivating cases for pep 560. 

The change was made as part of bpo-40185: Refactor typing.NamedTuple. Whilst the obvious alternative is "use dataclasses", they don't have the same runtime properties or implications as namedtuples.

----------
messages: 391705
nosy: FHTMitchell
priority: normal
severity: normal
status: open
title: Can't create generic NamedTuple as of py3.9
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Apr 23 12:45:51 2021
From: report at bugs.python.org (Rafi Hassan Chowdhury)
Date: Fri, 23 Apr 2021 16:45:51 +0000
Subject: [New-bugs-announce] [issue43924] print unexpected values in
 infinite loop
Message-ID: <1619196351.8.0.784934535356.issue43924@roundup.psfhosted.org>


Change by Rafi Hassan Chowdhury <rafihassan190041234 at gmail.com>:


----------
files: main.py
nosy: rafihassan190041234
priority: normal
severity: normal
status: open
title: print unexpected values in infinite loop
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49975/main.py

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

From report at bugs.python.org  Fri Apr 23 13:39:30 2021
From: report at bugs.python.org (=?utf-8?b?RnLDqWTDqXJpYyBHcm9zc2hhbnMtQW5kcsOp?=)
Date: Fri, 23 Apr 2021 17:39:30 +0000
Subject: [New-bugs-announce] [issue43925] Add hangul syllables to
 unicodedata.decomposititon
Message-ID: <1619199570.5.0.82333265185.issue43925@roundup.psfhosted.org>


New submission from Fr?d?ric Grosshans-Andr? <frederic.grosshans at gmail.com>:

Currently (python 3.8.6, unidata_version 12.1.0) unicodedata.decomposition outputs an empty string for hangul syllable (codepoints in the AC00..D7A3 range) while the decomposition is not empty: it is always two characters (either a LV syllable and a T Jamo or a L jamo and a V jamo). This decomposition is dedicible algorithmically (se ?3.12 of Unicode Standard). A python version of the algorithm is below (I don?t know C, so I can?t propose a patch). 

For each hangul syllable hs, I have used unicodedata.noramize to check that the NFC of the decomposition is indeed hs, that the decomposition is two codepoints long, that the NFD of both hs and the decompotsition coincide 

def hangulsyllabledecomposition(c):
    if not 0xAC00 <= ord(c) <= 0xD7A3 : raise ValueError('only Hangul syllables allowed')
    dLV, T = divmod(ord(c) - 0xAC00, 28)
    if T!=0 : #it is a LVT syllable, decomposed into LV:=dLV*19 and T 
        return f'{0xAC00+dLV*28:04X} {0x11A7+T:04X}'
    else : #it is a LVT syllable, decomposed into L , V
        L, V = divmod(dLV,21)
        return f'{0x1100+L:04X} {0x1161+V:04X}'
    # Constants used:
    # ==============
    # 0xAC00 : first syllable == 1st LV syllable 
    #                            NB: there is one LV syllable every 28 codepoints
    # 0xD7A3 : last Hangul syllable
    # 0x1100 : first L jamo
    # 0x1161 : first V jamo
    # 0x11A7 : one before the 1st T jamo (0x1148), since T=0 means no trailing
    #
    # (all number below restricted for modern jamos where this algorithm is relevant)
    # 19 : Number of L jamos (not used here)
    # 21 : Number of V jamos
    # 28 : Number of T jamos plus one (since no T jamo for LV syllable)

----------
components: Unicode
messages: 391715
nosy: ezio.melotti, frederic.grosshans, vstinner
priority: normal
severity: normal
status: open
title: Add hangul syllables to unicodedata.decomposititon
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 23 16:45:44 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Apr 2021 20:45:44 +0000
Subject: [New-bugs-announce] [issue43926] Clean metadata (importlib_metadata
 4.0)
Message-ID: <1619210744.46.0.218619498947.issue43926@roundup.psfhosted.org>


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

[importlib_metadata 4.0](https://importlib-metadata.readthedocs.io/en/latest/history.html#v4-0-0) introduced these important changes to the `metadata` function:

``PackageMetadata`` as returned by ``metadata()``
  and ``Distribution.metadata()`` now provides normalized
  metadata honoring PEP 566:

  - If a long description is provided in the payload of the
    RFC 822 value, it can be retrieved as the ``Description``
    field.
  - Any multi-line values in the metadata will be returned as
    such.
  - For any multi-line values, line continuation characters
    are removed. This backward-incompatible change means
    that any projects relying on the RFC 822 line continuation
    characters being present must be tolerant to them having
    been removed.
  - Add a ``json`` property that provides the metadata
    converted to a JSON-compatible form per PEP 566.

These changes would be a nice addition to Python 3.10.

----------
assignee: jaraco
components: Library (Lib)
messages: 391733
nosy: jaraco
priority: normal
severity: normal
status: open
title: Clean metadata (importlib_metadata 4.0)
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 23 17:51:05 2021
From: report at bugs.python.org (Tim Huegerich)
Date: Fri, 23 Apr 2021 21:51:05 +0000
Subject: [New-bugs-announce] [issue43927] Remove IOError references from the
 tutorial
Message-ID: <1619214665.17.0.886781359628.issue43927@roundup.psfhosted.org>


New submission from Tim Huegerich <hugetim at gmail.com>:

Although IOError has been merged into OSError since version 3.3, Section 8.5 of the Tutorial still uses it in examples. 

The Python 9.4 version of the tutorial features an example raising an IOError, which is then output as OSError, raising potential confusion unnecessarily.

The Python 3.10 documentation has partially resolved this issue but still retains a third instance of IOError. In this case, the IOError Exception is not actually raised, so the potentially confusing output is not present. Still, it seems preferable to remove it entirely.

----------
assignee: docs at python
components: Documentation
messages: 391743
nosy: docs at python, hugetim
priority: normal
severity: normal
status: open
title: Remove IOError references from the tutorial
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Apr 23 23:51:30 2021
From: report at bugs.python.org (Jeffrey Tse)
Date: Sat, 24 Apr 2021 03:51:30 +0000
Subject: [New-bugs-announce] [issue43928] Fix the typo in documentation
Message-ID: <1619236290.61.0.108206322719.issue43928@roundup.psfhosted.org>


Change by Jeffrey Tse <jeffreytse.mail at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, jeffreytse.mail
priority: normal
severity: normal
status: open
title: Fix the typo in documentation
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr 24 06:39:43 2021
From: report at bugs.python.org (Aritn Sarraf)
Date: Sat, 24 Apr 2021 10:39:43 +0000
Subject: [New-bugs-announce] [issue43929] Raise on threading.Event.__bool__
 due to ambiguous nature
Message-ID: <1619260783.59.0.920057566197.issue43929@roundup.psfhosted.org>


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

I'll sometimes find myself accidentally doing something like this (especially after a long break from using the threading module): 
```
stop_thread = threading.Event()
...
while not stop_thread:  # bug - bool(stop_thread) will always evaluate to True
    ...
```

Since the intention behind bool(event) is ambiguous and most likely often used improperly, I think that it would be a good idea to protect against this easy to produce bug, by overriding __bool__ to raise. There is precedent for this behavior in the popular numpy library, see here:
https://github.com/numpy/numpy/blob/623bc1fae1d47df24e7f1e29321d0c0ba2771ce0/numpy/core/src/multiarray/number.c#L829

Expanding on my thoughts:
1) Most operations on a threading.Event are associated with checking the truthiness of the underlying state of the Event. Meaning that there are many opportunities for bool(event) to be called improperly.
2) I can't think of any cases where  you would want to evaluate truthiness on anything other than the underlying "set" state of the Event. The one exception I can think of being the following (however, I believe this is generally accepted to be an anti-pattern, which I don't think should be considered a redeeming case for allowing bool(event)):
```
def my_func(event=None):
    event = event or threading.Event()
    ...
```
3) It is an easy addition to protect against this. Simply by raising in __bool__
4) The only backwards incompatibilities this could create are in cases where the event is being evaluated for truthiness incorrectly, and in the anti-pattern case described in point 2.

----------
components: Library (Lib)
messages: 391771
nosy: asarraf
priority: normal
severity: normal
status: open
title: Raise on threading.Event.__bool__ due to ambiguous nature
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/issue43929>
_______________________________________

From report at bugs.python.org  Sat Apr 24 10:13:55 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Bidoul?=)
Date: Sat, 24 Apr 2021 14:13:55 +0000
Subject: [New-bugs-announce] [issue43930] Update bundled pip to 21.1 and
 setuptools to 56.0.0
Message-ID: <1619273635.66.0.622596591495.issue43930@roundup.psfhosted.org>


New submission from St?phane Bidoul <stephane.bidoul at acsone.eu>:

I've just released pip 21.1, so this is to update the bundled copy (as well as updating setuptools).

----------
components: Library (Lib)
messages: 391777
nosy: sbidoul
priority: normal
severity: normal
status: open
title: Update bundled pip to 21.1 and setuptools to 56.0.0
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr 24 10:37:54 2021
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sat, 24 Apr 2021 14:37:54 +0000
Subject: [New-bugs-announce] [issue43931] Add the Python version to the API
 data.
Message-ID: <1619275074.12.0.00901483534926.issue43931@roundup.psfhosted.org>


New submission from Gabriele N Tornetta <phoenix1987 at gmail.com>:

When Python is embedded in other applications, it is not easy to determine which version of Python is being used. This change exposes the Python version as part of the API data. Tools like Austin (https://github.com/P403n1x87/austin) can benefit from this data when targeting applications like uWSGI, as the Python version can then be inferred systematically by looking at the exported symbols rather than relying on unreliable pattern matching or other hacks (like remote code execution etc...).

----------
components: C API
messages: 391779
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: Add the Python version to the API data.
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr 24 14:37:54 2021
From: report at bugs.python.org (Akshay K)
Date: Sat, 24 Apr 2021 18:37:54 +0000
Subject: [New-bugs-announce] [issue43932] f-string decimal has leading space
Message-ID: <1619289474.8.0.486564567214.issue43932@roundup.psfhosted.org>


New submission from Akshay K <akshayk1969 at icloud.com>:

When using a f-string to print a number with a certain number of decimal places, the number is printed with a leading space.

----------
components: Interpreter Core
files: fstringdemo.py
messages: 391789
nosy: Axeinator, eric.smith
priority: normal
severity: normal
status: open
title: f-string decimal has leading space
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49981/fstringdemo.py

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

From report at bugs.python.org  Sat Apr 24 15:56:33 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 24 Apr 2021 19:56:33 +0000
Subject: [New-bugs-announce] [issue43933] Regression in python3.10 with
 traceback frame having lineno of -1
Message-ID: <1619294193.93.0.370565760758.issue43933@roundup.psfhosted.org>


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

This is breaking pytest for failed assertions: https://github.com/pytest-dev/pytest/pull/8227

It also breaks the traceback in the output below

Here's a minimal example:

```python
class Boom:
    def __enter__(self):
        return self
    def __exit__(self, *_):
        raise AssertionError('boom!')


def main() -> int:
    with Boom():
        raise AssertionError('hi')


if __name__ == '__main__':
    exit(main())
```

On python3.9 you get this:

```
Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 10, in main
    raise AssertionError('hi')
AssertionError: hi

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 14, in <module>
    exit(main())
  File "/home/asottile/workspace/cpython/t.py", line 10, in main
    raise AssertionError('hi')
  File "/home/asottile/workspace/cpython/t.py", line 5, in __exit__
    raise AssertionError('boom!')
AssertionError: boom!
```

output in python3.10:

```
Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 10, in main
    raise AssertionError('hi')
AssertionError: hi

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 14, in <module>
    exit(main())
  File "/home/asottile/workspace/cpython/t.py", line -1, in main
  File "/home/asottile/workspace/cpython/t.py", line 5, in __exit__
    raise AssertionError('boom!')
AssertionError: boom!
```

Notice the second to last frame is now missing and invalid (line -1)

I bisected this and found this is the culprit:


https://github.com/python/cpython/commit/3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67
https://github.com/python/cpython/pull/24202

```
3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67 is the first bad commit
commit 3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67
Author: Mark Shannon <mark at hotpy.org>
Date:   Wed Jan 13 12:05:43 2021 +0000

    bpo-42908: Mark cleanup code at end of try-except and with artificial (#24202)
    
    * Mark bytecodes at end of try-except as artificial.
    
    * Make sure that the CFG is consistent throughout optimiization.
    
    * Extend line-number propagation logic so that implicit returns after 'try-except' or 'with' have the correct line numbers.
    
    * Update importlib

 Lib/test/test_dis.py          |    2 +-
 Lib/test/test_sys_settrace.py |   40 +
 Python/compile.c              |  135 +-
 Python/importlib.h            | 3153 ++++++++++++++---------------
 Python/importlib_external.h   | 4489 ++++++++++++++++++++---------------------
 Python/importlib_zipimport.h  | 1013 +++++-----
 6 files changed, 4473 insertions(+), 4359 deletions(-)
bisect run success
```

which appears to be due to bpo-42908

----------
messages: 391795
nosy: Anthony Sottile, Mark.Shannon, pablogsal
priority: normal
severity: normal
status: open
title: Regression in python3.10 with traceback frame having lineno of -1
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Apr 24 16:20:48 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 24 Apr 2021 20:20:48 +0000
Subject: [New-bugs-announce] [issue43934] Minimal version of SQLite3 - 3.26 ?
Message-ID: <1619295648.28.0.879018174347.issue43934@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

After reading this issue: https://bugs.python.org/msg370266, I think SQLite 3.26.0 could be the minimal version for Python 3.10.


I have checked the following distributions

CentOS 8: stable : 8.3.2011: 3.26.0
Debian 10: stable : 10 : 3.27.2
Ubuntu 20.04: stable : 20.04: 3.31.1

CentOS 7: oldstable : 7.9.2009: 3.7.17
Debian 9: oldstable : 9.13: 3.16.2

----------
messages: 391797
nosy: matrixise
priority: normal
severity: normal
status: open
title: Minimal version of SQLite3 - 3.26 ?
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr 24 16:35:56 2021
From: report at bugs.python.org (=?utf-8?q?Tarjei_B=C3=A6rland?=)
Date: Sat, 24 Apr 2021 20:35:56 +0000
Subject: [New-bugs-announce] [issue43935] Fix typo in Turtle.back docstring
Message-ID: <1619296556.86.0.24657998959.issue43935@roundup.psfhosted.org>


Change by Tarjei B?rland <tarjeibaerland at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, tarjeiba
priority: normal
severity: normal
status: open
title: Fix typo in Turtle.back docstring
versions: Python 3.10

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

From report at bugs.python.org  Sat Apr 24 17:22:05 2021
From: report at bugs.python.org (Barney Gale)
Date: Sat, 24 Apr 2021 21:22:05 +0000
Subject: [New-bugs-announce] [issue43936] os.path.realpath() normalizes
 paths before resolving links on Windows
Message-ID: <1619299325.99.0.263866939052.issue43936@roundup.psfhosted.org>


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

Capturing a write-up by eryksun on GitHub into a new bug.

Link: https://github.com/python/cpython/pull/25264#pullrequestreview-631787754

> `nt._getfinalpathname()` opens a handle to a file/directory with `CreateFileW()` and calls `GetFinalPathNameByHandleW()`. The latter makes a few system calls to get the final opened path in the filesystem (e.g. "\Windows\explorer.exe") and the canonical DOS name of the volume device on which the filesystem is mounted (e.g. "\Device\HarddiskVolume2" -> "\\?\C:") in order to return a canonical DOS path (e.g. "\\?\C:\Windows\explorer.exe").
> 
> Opening a handle with `CreateFileW()` entails first getting a fully-qualified and normalized NT path, which, among other things, entails resolving ".." components naively in the path string. This does not take reparse points such as symlinks and mountpoints into account. The only time Windows parses ".." components in an opened path the way POSIX does is in the kernel when they're in the target path of a relative symlink.
> 
> `nt.readlink()` opens a handle to the file with the flag `FILE_FLAG_OPEN_REPARSE_POINT`. If the final path component is a reparse point, it opens it instead of traversing it. Then the reparse point is read with the filesystem control request, `FSCTL_GET_REPARSE_POINT`. System symlinks and mountpoints (`IO_REPARSE_TAG_SYMLINK` and `IO_REPARSE_TAG_MOUNT_POINT`) are the only supported name-surrogate reparse-point types, though `os.stat()` and `os.lstat()` handle all name-surrogate types as 'links'. Moreover, only symlinks get the `S_IFLNK` mode flag in a stat result, because they're the only ones we can create with `os.symlink()` to satisfy the usage `if os.path.islink(src): os.symlink(os.readlink(src), dst)`.
>
> > What would it take to do a POSIX-style "normalize as we resolve",
> > and would we want to? I guess we'd need to call nt._getfinalpathname()
> > on each path component in turn (C:, C:\Users, C:\Users\Barney etc),
> > which from my pretty basic Windows knowledge might be rather slow if
> > that involves file handles.
> 
> You asked, so I decided to write up an outline of what implementing a POSIX-style `realpath()` might look like in Windows. At its core, it's similar to POSIX: lstat(), and, for a symlink, readlink() and recur. The equivalent calls in Windows are the following:
> 
>     * `CreateFileW()` (open a handle)
> 
>     * `GetFileInformationByHandleEx()`: `FileAttributeTagInfo`
> 
>     * `DeviceIoControl()`: `FSCTL_GET_REPARSE_POINT`
> 
> 
> A symlink has the reparse tag `IO_REPARSE_TAG_SYMLINK`.
> 
> Filesystem mountpoints (aka junctions, which are like Unix bind mountpoints) must be retained in the resolved path in order to correctly resolve relative symlinks such as "\spam" (relative to the resolved device) and "..\..\spam". Anyway, this is consistent with the UNC case, since mountpoints on a remote server can never be resolved (i.e. a final UNC path never resolves mountpoints).
> 
> Here are some of the notable differences compared to POSIX:
> 
>     * If the source path is not a "\\?\" verbatim path, `GetFullPathNameW()` must be called initially.  However, ".." components in the target path of a relative symlink must be resolved the POSIX way, else symlinks in the target path may be removed incorrectly before their target is resolved (e.g. "foo\symlink\..\bar" incorrectly resolved as "foo\bar"). The opened path is initially normalized as follows:
>       
>       * replace forward slashes with backslashes
>       * collapse repeated backslashes (except the UNC root must have exactly two backslashes)
>       * resolve a relative path (e.g. "spam"), drive-relative path (e.g. "Z:spam"), or rooted path (e.g. "\spam") as a fully-qualified path (e.g. "Z:\eggs\spam")
>       * resolve "." and ".." components in the opened path (naive to symlinks)
>       * strip trailing spaces and dots from the final component (e.g. "C:\spam. . ." -> "C:\spam")
>       * resolve reserved device names in the final component of a non-UNC path (e.g. "C:\nul" -> "\\.\nul")
> 
>     * Substitute drives (e.g. created by "subst.exe", or `DefineDosDeviceW`) and mapped drives (e.g. created by "net.exe", or `WNetAddConnection2W`) must be resolved, respectively via `QueryDosDeviceW()` and `WNetGetUniversalNameW()`. Like all DOS 'devices', these drives are implemented as object symlinks (i.e. symlinks in the object namespace, not to be confused with filesystem symlinks). The target path of these drives, however, is not a Device object, but rather a filesystem path on a device that can include any number of path components, some of which may be filesystem symlinks that need to be resolved. Normally when a path is opened, the system object manager reparses all DOS 'devices' to the path of an actual Device object, or a path on a Device object, before the I/O manager's parse routine ever sees the path. Such drives need to be resolved whenever parsing starts or restarts at a drive, but the result can be cached in case multiple filesystem symlinks target the same drive.
>       
>       * Substitute drives can target paths on other substitute drives, so `QueryDosDeviceW()` has to be called in a loop that accumulates the tail path components until it reaches a real device (i.e. a target path that doesn't begin with "\??\").
>       * `WNetGetUniversalNameW()` has to be called after resolving substitute drives. It resolves the underlying UNC  path of a mapped drive. The target path of the object symlink that implements a mapped drive is of the form "\Device\<redirector device name>\;<something>\server\share\some\filesystem\path". The "redirector device name" component is usually (post Windows Vista) an object symlink to a path on the system's Multiple UNC Provider (MUP) device, "\Device\Mup". The mapped-drive target path ultimately resolves to a redirected filesystem that's mounted in the MUP device namespace at the "share" name. This is an implementation detail of the filesystem redirector and MUP device, which the Multiple Provider Router (MPR) WNet API encapsulates. For example, for the mapped drive path "Z:\spam\eggs", it returns a UNC path of the form "\\server\share\some\filesystem\path\spam\eggs".
> 
>     * A join that tries to resolve ".." against the drive or share root path must fail, whereas this is ignored for the root path in POSIX. For example, `symlink_join("C:\\", "..\\spam")` must fail, since the system would fail an open that tried to reparse that symlink target.
> 
>     * At the end, the resolved path should be tested to try to remove "\\?\" if the source path didn't have this prefix. Call `GetFullPathNameW()` to check for a reserved name in the final component and `PathCchCanonicalizeEx()` to check for long-path support. (The latter calls the system runtime library function `RtlAreLongPathsEnabled`, but that's an undocumented implementation detail.)
> 
> 
> `GetFinalPathNameByHandleW()` is not required. Optionally, it can be called for the last valid component if the caller wants a final path with all mountpoints resolved, i.e. add a `final_path=False` option. Of course, a final UNC path must retain mountpoints, so there's nothing we can do in that case. It's fine that this `realpath()` implementation would return a path that contains mountpoints in Windows (as the current implementation also does for UNC paths). They are not symlinks, and this matches the behavior of POSIX.
> 
> I'd include a warning in the documentation that getting a final path via `GetFinalPathNameByHandleW()` in the non-strict case may be dysfunctional. The unresolved tail end of the path may become valid again if a server or device comes back online. If the unresolved part contains symlinks with relative targets such as "\spam" and "..\..\spam", and the `realpath()` call resolved away mountpoints, the reminaing path may not resolve correctly against the final path, as compared to how it would resolve against the original path. It definitely will not resolve the same for a rooted target path such as "\spam" if the last resolved reparse point in the original path was a mountpoint, since it will reparse to the root path of the mountpoint device instead of the original opened device, or instead of the last resolved device of a symlink in the path.

----------
components: Library (Lib)
messages: 391804
nosy: barneygale
priority: normal
severity: normal
status: open
title: os.path.realpath() normalizes paths before resolving links on Windows
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/issue43936>
_______________________________________

From report at bugs.python.org  Sun Apr 25 06:31:39 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Apr 2021 10:31:39 +0000
Subject: [New-bugs-announce] [issue43937] Turtle uses the default root window
Message-ID: <1619346699.57.0.755542402356.issue43937@roundup.psfhosted.org>


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

Some of methods in the turtle module implicitly use the default root window: call global mainloop() and create PhotoImage without specifying the master window. It can cause a problem if multiple root windows are used.

----------
components: Library (Lib)
messages: 391849
nosy: gregorlingl, serhiy.storchaka, willingc
priority: normal
severity: normal
status: open
title: Turtle uses the default root window
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 25 12:25:34 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 25 Apr 2021 16:25:34 +0000
Subject: [New-bugs-announce] [issue43938] Document that
 dataclasses.FrozenInstanceError derives from AttributeError
Message-ID: <1619367934.66.0.118444398997.issue43938@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

This is a newcomer friendly issue. The documentation just needs a sentence that FrozenInstanceError is derived from AttributeError.

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 391861
nosy: docs at python, eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that dataclasses.FrozenInstanceError derives from AttributeError
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 25 12:58:46 2021
From: report at bugs.python.org (DaRoee)
Date: Sun, 25 Apr 2021 16:58:46 +0000
Subject: [New-bugs-announce] [issue43939] Deadlock in logging
Message-ID: <1619369926.8.0.917759570645.issue43939@roundup.psfhosted.org>


New submission from DaRoee <roee.drucker at gmail.com>:

I've recently encountered a weird bug. To make a long story short, I?ve been using an external package to make sure my threads stop working in time, and appearently it?s been using ctypes.pythonapi.PyThreadState_SetAsyncExc.
There is a slight chance, that this code that is literally injecting an exception in the thread, will throw an exception in the handle function of the logger, right after the acquire. This will make the whole process deadlocked (only the thread with the exception will be able to continue logging) once the other threads try to log.

While I totally understand that this is not a casual use case, I think that the logger should be able to handle situations such as this...
The good news is that I?ve created a test (attached) that once you run it with pytest it?ll reproduce constantly (even though it?s a statistical bug), and the solution for this is relatively easy. Once we change the lock to use context manager the whole action is much more atomic, making the test pass constantly.

I?d be happy to help solve it, and replace locks to context manager usage throughout the file (or whatever the maintainers see fit for this).

----------
components: Library (Lib)
files: reproduction_test.py
messages: 391862
nosy: DaRoee
priority: normal
severity: normal
status: open
title: Deadlock in logging
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49983/reproduction_test.py

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

From report at bugs.python.org  Sun Apr 25 22:52:44 2021
From: report at bugs.python.org (Huang Yang)
Date: Mon, 26 Apr 2021 02:52:44 +0000
Subject: [New-bugs-announce] [issue43940] int casting to float results to a
 different value in memory
Message-ID: <1619405564.97.0.595981007242.issue43940@roundup.psfhosted.org>


New submission from Huang Yang <yang.huang at intel.com>:

from ctypes import *
import struct

i = int('7f94e57c', 16)
cp = pointer(c_int(i))
fp = cast(cp, POINTER(c_float))
print(fp.contents.value) # nan
print(struct.pack(">f", fp.contents.value).hex()) # 7fd4e57c

# value changed: 7f94e57c -> 7fd4e57c

----------
components: Library (Lib), ctypes
messages: 391876
nosy: yang8621
priority: normal
severity: normal
status: open
title: int casting to float results to a different value in memory
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr 26 01:02:16 2021
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 26 Apr 2021 05:02:16 +0000
Subject: [New-bugs-announce] [issue43941] Unit test failure in test_gdb only
 with -O0
Message-ID: <1619413336.26.0.680975027921.issue43941@roundup.psfhosted.org>


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

Recent Python source trees fail a regression test in test_gdb.  Oddly, the behavior only appears up when optimization is turned off.

To reproduce:

% git clone cpython buildtrunk
% cd buildtrunk
% ./configure
% vi Makefile  # change "-O3" to "-O0" !!
% make -j
% ./python -m test -v test_gdb

You'll be rewarded with one failure:

======================================================================
FAIL: test_wrapper_call (test.test_gdb.PyBtTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/larry/src/python/buildtrunk/Lib/test/test_gdb.py", line 947, in test_wrapper_call
    self.assertRegex(gdb_output,
AssertionError: Regex didn't match: "<method-wrapper u?'__init__' of MyList object at " not found in 'Breakpoint 1 at 0x281f5a: file Python/bltinmodule.c, line 1207.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".\n\nBreakpoint 1, builtin_id (self=<cfunction_enter_call+35>, v=<unknown at remote 0x7fffffffc7b0>) at Python/bltinmodule.c:1207\n1207\t{\nBreakpoint 2: file Objects/descrobject.c, line 1386.\n\nBreakpoint 2, wrapper_call (wp=<unknown at remote 0x555555973820>, args=<unknown at remote 0x55555581dee8>, kwds=<unknown at remote 0x5555555bde85>) at Objects/descrobject.c:1386\n1386\t{\nTraceback (most recent call first):\n  <unknown at remote 0x555555973820>\n  File "<string>", line 4, in __init__\n  File "<string>", line 7, in <module>\n'

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

I just reproduced this with version 3c4850e222388889426e250ff43308e4802dc582 .  Note that if you don't change the Makefile, and leave the optimization level at "-O3", you won't see this test failure.

Pablo, I nosied you just to get it on your radar.  Good luck with getting Python 3.10 over the finish line!

----------
components: Library (Lib)
keywords: 3.10regression
messages: 391878
nosy: larry, pablogsal
priority: normal
severity: normal
stage: needs patch
status: open
title: Unit test failure in test_gdb only with -O0
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr 26 05:29:05 2021
From: report at bugs.python.org (Reuben Thomas)
Date: Mon, 26 Apr 2021 09:29:05 +0000
Subject: [New-bugs-announce] [issue43942] RawDescriptionHelpFormatter seems
 to be ignored for argument descriptions
Message-ID: <1619429345.55.0.132994171177.issue43942@roundup.psfhosted.org>


New submission from Reuben Thomas <rrt at sc3d.org>:

The documentation seems very clear on this subject:

"RawTextHelpFormatter maintains whitespace for all sorts of help text, including argument descriptions. However, multiple new lines are replaced with one."

But consider the following code:

```
from argparse import ArgumentParser, RawDescriptionHelpFormatter

parser = ArgumentParser(
  description='A simple templating system.',
  epilog='Use `-\' as a file name to indicate standard input or output.',
  formatter_class=RawDescriptionHelpFormatter,
)
parser.add_argument(
  '--verbose',
  help='show on standard error the path being built,\nand the names of files built, included and pasted'
)
args = parser.parse_args()
```

Then try running it in a suitably-sized terminal:

$ python3 test.py --help
usage: test.py [-h] [--verbose VERBOSE]

A simple templating system.

optional arguments:
  -h, --help         show this help message and exit
  --verbose VERBOSE  show on standard error the path being built, and the names of files built, included and pasted

Use `-' as a file name to indicate standard input or output.
```

The \n in the help for the `--verbose` argument is not respected.

----------
components: Library (Lib)
messages: 391890
nosy: rrt
priority: normal
severity: normal
status: open
title: RawDescriptionHelpFormatter seems to be ignored for argument descriptions
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 26 08:53:27 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 26 Apr 2021 12:53:27 +0000
Subject: [New-bugs-announce] [issue43943] test_ssl fails in the macos CI
Message-ID: <1619441607.06.0.479500365034.issue43943@roundup.psfhosted.org>


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

Check out this build:

https://github.com/python/cpython/pull/25584/checks?check_run_id=2437718845

Here, test_ssl fails in the macos CI target:

1 test failed:
    test_ssl

20 tests skipped:
    test_devpoll test_epoll test_gdb test_idle test_ioctl test_msilib
    test_multiprocessing_fork test_ossaudiodev test_spwd
    test_startfile test_tcl test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_turtle test_winconsoleio test_winreg
    test_winsound test_zipfile64
0:18:53 load avg: 3.12
0:18:53 load avg: 3.12 Re-running failed tests in verbose mode
0:18:53 load avg: 3.12 Re-running test_ssl in verbose mode
test_ssl: testing with 'OpenSSL 1.1.1k  25 Mar 2021' (1, 1, 1, 11, 15)
          under Mac ('10.15.7', ('', '', ''), 'x86_64')
          HAS_SNI = True
          OP_ALL = 0x80000054
          OP_NO_TLSv1_1 = 0x10000000
test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
test_cert_store_stats (test.test_ssl.ContextTests) ... ok
test_check_hostname (test.test_ssl.ContextTests) ... ok
test_ciphers (test.test_ssl.ContextTests) ... ok
test_constructor (test.test_ssl.ContextTests) ... ok
test_context_client_server (test.test_ssl.ContextTests) ... ok
test_context_custom_class (test.test_ssl.ContextTests) ... ok
test_create_default_context (test.test_ssl.ContextTests) ... ok
test_get_ca_certs (test.test_ssl.ContextTests) ... ok
test_get_ciphers (test.test_ssl.ContextTests) ... ok
test_hostname_checks_common_name (test.test_ssl.ContextTests) ... ok
test_load_cert_chain (test.test_ssl.ContextTests) ... ok
test_load_default_certs (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env_windows (test.test_ssl.ContextTests) ... skipped 'Windows specific'
test_load_dh_params (test.test_ssl.ContextTests) ... ok
test_load_verify_cadata (test.test_ssl.ContextTests) ... ok
test_load_verify_locations (test.test_ssl.ContextTests) ... ok
test_min_max_version (test.test_ssl.ContextTests) ... ok
test_num_tickest (test.test_ssl.ContextTests) ... ok
test_options (test.test_ssl.ContextTests) ... ok
test_python_ciphers (test.test_ssl.ContextTests) ... ok
test_security_level (test.test_ssl.ContextTests) ... ok
test_session_stats (test.test_ssl.ContextTests) ... ok
test_set_default_verify_paths (test.test_ssl.ContextTests) ... ok
test_set_ecdh_curve (test.test_ssl.ContextTests) ... ok
test_sni_callback (test.test_ssl.ContextTests) ... ok
test_sni_callback_refcycle (test.test_ssl.ContextTests) ... ok
test_verify_flags (test.test_ssl.ContextTests) ... ok
test_verify_mode_protocol (test.test_ssl.ContextTests) ... ok
test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
test_asn1object (test.test_ssl.BasicSocketTests) ... ok
test_cert_time_to_seconds (test.test_ssl.BasicSocketTests) ... ok
test_cert_time_to_seconds_locale (test.test_ssl.BasicSocketTests) ... skipped 'locale-specific month name needs to be different from C locale'
test_cert_time_to_seconds_timezone (test.test_ssl.BasicSocketTests) ... skipped 'local time needs to be different from UTC'
test_connect_ex_error (test.test_ssl.BasicSocketTests) ... ok
test_constants (test.test_ssl.BasicSocketTests) ... ok
test_dealloc_warn (test.test_ssl.BasicSocketTests) ... ok
test_empty_cert (test.test_ssl.BasicSocketTests)
Wrapping with an empty cert file ... ok
test_enum_certificates (test.test_ssl.BasicSocketTests) ... skipped 'Windows specific'
test_enum_crls (test.test_ssl.BasicSocketTests) ... skipped 'Windows specific'
test_errors_sslwrap (test.test_ssl.BasicSocketTests) ... ok
test_get_default_verify_paths (test.test_ssl.BasicSocketTests) ... ok
test_malformed_cert (test.test_ssl.BasicSocketTests)
Wrapping with a badly formatted certificate (syntax error) ... ok
test_malformed_key (test.test_ssl.BasicSocketTests)
Wrapping with a badly formatted key (syntax error) ... ok
test_match_hostname (test.test_ssl.BasicSocketTests) ... ok
test_openssl_version (test.test_ssl.BasicSocketTests) ... ok
test_parse_all_sans (test.test_ssl.BasicSocketTests) ... ok
test_parse_cert (test.test_ssl.BasicSocketTests) ... 
{'OCSP': ('http://ocsp.verisign.com',),
 'caIssuers': ('http://SVRIntl-G3-aia.verisign.com/SVRIntlG3.cer',),
 'crlDistributionPoints': ('http://SVRIntl-G3-crl.verisign.com/SVRIntlG3.crl',),
 'issuer': ((('countryName', 'US'),),
            (('organizationName', 'VeriSign, Inc.'),),
            (('organizationalUnitName', 'VeriSign Trust Network'),),
            (('organizationalUnitName',
              'Terms of use at https://www.verisign.com/rpa (c)10'),),
            (('commonName', 'VeriSign Class 3 International Server CA - G3'),)),
 'notAfter': 'Sep 20 23:59:59 2012 GMT',
 'notBefore': 'Sep 21 00:00:00 2011 GMT',
 'serialNumber': '2EE6EA7640A075CEE5005F4D7C79549A',
 'subject': ((('countryName', 'FI'),),
             (('stateOrProvinceName', 'Espoo'),),
             (('localityName', 'Espoo'),),
             (('organizationName', 'Nokia'),),
             (('organizationalUnitName', 'BI'),),
             (('commonName', 'projects.developer.nokia.com'),)),
 'subjectAltName': (('DNS', 'projects.developer.nokia.com'),
                    ('DNS', 'projects.forum.nokia.com')),
 'version': 3}
ok
test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests) ... 
{'issuer': ((('countryName', 'US'),),
            (('stateOrProvinceName', 'Oregon'),),
            (('localityName', 'Beaverton'),),
            (('organizationName', 'Python Software Foundation'),),
            (('organizationalUnitName', 'Python Core Development'),),
            (('commonName', 'null.python.org\x00example.org'),),
            (('emailAddress', 'python-dev at python.org'),)),
 'notAfter': 'Aug  7 13:12:52 2013 GMT',
 'notBefore': 'Aug  7 13:11:52 2013 GMT',
 'serialNumber': '00',
 'subject': ((('countryName', 'US'),),
             (('stateOrProvinceName', 'Oregon'),),
             (('localityName', 'Beaverton'),),
             (('organizationName', 'Python Software Foundation'),),
             (('organizationalUnitName', 'Python Core Development'),),
             (('commonName', 'null.python.org\x00example.org'),),
             (('emailAddress', 'python-dev at python.org'),)),
 'subjectAltName': (('DNS', 'altnull.python.org\x00example.com'),
                    ('email', 'null at python.org\x00user at example.org'),
                    ('URI', 'http://null.python.org\x00http://example.org'),
                    ('IP Address', '192.0.2.1'),
                    ('IP Address', '2001:DB8:0:0:0:0:0:1')),
 'version': 3}
ok
test_parse_cert_CVE_2019_5010 (test.test_ssl.BasicSocketTests) ... 
{'issuer': ((('countryName', 'UK'),), (('commonName', 'cody-ca'),)),
 'notAfter': 'Jun 14 18:00:58 2028 GMT',
 'notBefore': 'Jun 18 18:00:58 2018 GMT',
 'serialNumber': '02',
 'subject': ((('countryName', 'UK'),),
             (('commonName', 'codenomicon-vm-2.test.lal.cisco.com'),)),
 'subjectAltName': (('DNS', 'codenomicon-vm-2.test.lal.cisco.com'),),
 'version': 3}
ok
test_private_init (test.test_ssl.BasicSocketTests) ... ok
test_purpose_enum (test.test_ssl.BasicSocketTests) ... ok
test_random (test.test_ssl.BasicSocketTests) ... 
 RAND_status is 1 (sufficient randomness)
ok
test_read_write_zero (test.test_ssl.BasicSocketTests) ...  server:  new connection from ('127.0.0.1', 52385)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_refcycle (test.test_ssl.BasicSocketTests) ... ok
test_server_side (test.test_ssl.BasicSocketTests) ... ok
test_str_for_enums (test.test_ssl.BasicSocketTests) ... ok
test_timeout (test.test_ssl.BasicSocketTests) ... ok
test_tls_unique_channel_binding (test.test_ssl.BasicSocketTests) ... ok
test_unknown_channel_binding (test.test_ssl.BasicSocketTests) ... ok
test_unsupported_dtls (test.test_ssl.BasicSocketTests) ... ok
test_wrapped_unconnected (test.test_ssl.BasicSocketTests) ... ok
test_bad_server_hostname (test.test_ssl.SSLErrorTests) ... ok
test_lib_reason (test.test_ssl.SSLErrorTests) ... ok
test_str (test.test_ssl.SSLErrorTests) ... ok
test_subclass (test.test_ssl.SSLErrorTests) ... ok
test_buffer_types (test.test_ssl.MemoryBIOTests) ... ok
test_eof (test.test_ssl.MemoryBIOTests) ... ok
test_error_types (test.test_ssl.MemoryBIOTests) ... ok
test_pending (test.test_ssl.MemoryBIOTests) ... ok
test_read_write (test.test_ssl.MemoryBIOTests) ... ok
test_private_init (test.test_ssl.SSLObjectTests) ... ok
test_unwrap (test.test_ssl.SSLObjectTests) ... ok
test_bio_handshake (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52391)
Needed 2 calls to complete do_handshake().
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
Needed 3 calls to complete unwrap().
ok
test_bio_read_write_data (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52393)
Needed 2 calls to complete do_handshake().
Needed 1 calls to complete write().
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
Needed 4 calls to complete read().
Needed 2 calls to complete unwrap().
ok
test_ciphers (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52395)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52396)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_connect (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52398)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52399)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_connect_cadata (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52401)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52402)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_connect_capath (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52404)

 server:  bad connection attempt from ('127.0.0.1', 52404):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 OSError: [Errno 41] Protocol wrong type for socket
ERROR
test_connect_ex (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52407)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_connect_fail (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52409)

 server:  bad connection attempt from ('127.0.0.1', 52409):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:969)
ok
test_connect_with_context (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52411)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52412)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52413)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_connect_with_context_fail (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52415)

 server:  bad connection attempt from ('127.0.0.1', 52415):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:969)
ok
test_context_setget (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52417)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_get_ca_certs_capath (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52419)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_get_server_certificate (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52422)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52424)

Verified certificate for localhost:52420 is
-----BEGIN CERTIFICATE-----
MIIF8TCCBFmgAwIBAgIJAMstgJlaaVJcMA0GCSqGSIb3DQEBCwUAME0xCzAJBgNV
BAYTAlhZMSYwJAYDVQQKDB1QeXRob24gU29mdHdhcmUgRm91bmRhdGlvbiBDQTEW
MBQGA1UEAwwNb3VyLWNhLXNlcnZlcjAeFw0xODA4MjkxNDIzMTZaFw0zNzEwMjgx
NDIzMTZaMF8xCzAJBgNVBAYTAlhZMRcwFQYDVQQHDA5DYXN0bGUgQW50aHJheDEj
MCEGA1UECgwaUHl0aG9uIFNvZnR3YXJlIEZvdW5kYXRpb24xEjAQBgNVBAMMCWxv
Y2FsaG9zdDCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAMW0s615CVCi
M3vO2S7HubSGYYqQ/WGHSFsqpNwPzuOQsCoDBlZ6eNkyMJttne8/4A5sIiRggrM9
djtiL4fkzc7aZcgPGgcaMv8Za2gTIM1e+b1QL4xG5I6rYxoscdAbRHHZPFxisxVQ
ztv3euk3UsZGsK/WAhJczgS8QmigBHsBp2PSkb+jR+oMB0WMfpBluGfWJmV754Zu
Nx92Af8fQXx2fU88ahWIdeJxuxDiQHrTTY9/5pc/hvZAoBt+XI0cQoc8cQ45NesW
Mx1z5uopbbh6kSwxkjn2rH2FT/hG+nf+/68TBMvs2buKWm3NmfZy8YJbf0sLSc1g
s7OQ7cfzHADvmHq7KR0H5Y7+/YIogr0z9k771A2uZqiR8oNqYKTf1vyGULA0voux
Wm93ddNLlafhhaf3YSqKW1Qkmg+julztVN1YKDjNUWfhDxmHg0U2f+pMHyUQyCuw
1NXlzJnvOGgGJQxI7jluajY2ycTtx78lSGWp7m6HQ9PUwgGBNX6gMwIDAQABo4IB
wDCCAbwwFAYDVR0RBA0wC4IJbG9jYWxob3N0MA4GA1UdDwEB/wQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUhXUQJdAsgFAkGltXcN61y3GpO3swfQYDVR0jBHYwdIAUs4qgorpx8agkedSk
WyU2FR5JyM2hUaRPME0xCzAJBgNVBAYTAlhZMSYwJAYDVQQKDB1QeXRob24gU29m
dHdhcmUgRm91bmRhdGlvbiBDQTEWMBQGA1UEAwwNb3VyLWNhLXNlcnZlcoIJAMst
gJlaaVJbMIGDBggrBgEFBQcBAQR3MHUwPAYIKwYBBQUHMAKGMGh0dHA6Ly90ZXN0
Y2EucHl0aG9udGVzdC5uZXQvdGVzdGNhL3B5Y2FjZXJ0LmNlcjA1BggrBgEFBQcw
AYYpaHR0cDovL3Rlc3RjYS5weXRob250ZXN0Lm5ldC90ZXN0Y2Evb2NzcC8wQwYD
VR0fBDwwOjA4oDagNIYyaHR0cDovL3Rlc3RjYS5weXRob250ZXN0Lm5ldC90ZXN0
Y2EvcmV2b2NhdGlvbi5jcmwwDQYJKoZIhvcNAQELBQADggGBAJXzVrvVjHC90d7a
Y7Ap19tgJ9ZZ/WEbMMbQXXN9NOFo4yimieZgvYnTDvRyrXJ2+IYh/XU8+G2+nATh
ggNpbK7QVbpe8sr1D47W2Y3IVkb0+Kx0Khl7jkdwH/v7vWkCoaVKbiEcBBQVVb+/
JEPIFwO+Pizq28ivHf1S39YVSZ7CRGnv8UVDg7IezxQcEz/+nHHL5xsYVjanr0Tx
C6F5REb5Q0Yp2LDKSU1lYNP2jnS8Yp4ejUspmrQN8KJ3WzTkES+nJcXlB3YSrr51
cxXkCn1TOFY/eW1uyu2Aq1btfosc5+PUYjAicOcpsgM8/vo98DbATRGimdMpMSe4
xbgVozxPm3NeK7L7y/11R7gXvSHY5sG5/3OB2CUIbQheHKWDUN5n5trQjlrT8iqx
P7iAIQdqcRVtBetRs1mN1BVGfgKoEwEWmb0DzHBxKiMWeK/R1QGdBLRjk5oEOpIu
5n5zk6X+UJu9DupUhm985RR3/sIoWkoO1y2M6e1hKbJT/2wEvA==
-----END CERTIFICATE-----

 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_get_server_certificate_fail (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52427)
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:969)

 server:  bad connection attempt from ('127.0.0.1', 52427):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:969)
ok
test_get_server_certificate_sni (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52430)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52432)

Verified certificate for localhost:52428 is
-----BEGIN CERTIFICATE-----
MIIF8TCCBFmgAwIBAgIJAMstgJlaaVJcMA0GCSqGSIb3DQEBCwUAME0xCzAJBgNV
BAYTAlhZMSYwJAYDVQQKDB1QeXRob24gU29mdHdhcmUgRm91bmRhdGlvbiBDQTEW
MBQGA1UEAwwNb3VyLWNhLXNlcnZlcjAeFw0xODA4MjkxNDIzMTZaFw0zNzEwMjgx
NDIzMTZaMF8xCzAJBgNVBAYTAlhZMRcwFQYDVQQHDA5DYXN0bGUgQW50aHJheDEj
MCEGA1UECgwaUHl0aG9uIFNvZnR3YXJlIEZvdW5kYXRpb24xEjAQBgNVBAMMCWxv
Y2FsaG9zdDCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAMW0s615CVCi
M3vO2S7HubSGYYqQ/WGHSFsqpNwPzuOQsCoDBlZ6eNkyMJttne8/4A5sIiRggrM9
djtiL4fkzc7aZcgPGgcaMv8Za2gTIM1e+b1QL4xG5I6rYxoscdAbRHHZPFxisxVQ
ztv3euk3UsZGsK/WAhJczgS8QmigBHsBp2PSkb+jR+oMB0WMfpBluGfWJmV754Zu
Nx92Af8fQXx2fU88ahWIdeJxuxDiQHrTTY9/5pc/hvZAoBt+XI0cQoc8cQ45NesW
Mx1z5uopbbh6kSwxkjn2rH2FT/hG+nf+/68TBMvs2buKWm3NmfZy8YJbf0sLSc1g
s7OQ7cfzHADvmHq7KR0H5Y7+/YIogr0z9k771A2uZqiR8oNqYKTf1vyGULA0voux
Wm93ddNLlafhhaf3YSqKW1Qkmg+julztVN1YKDjNUWfhDxmHg0U2f+pMHyUQyCuw
1NXlzJnvOGgGJQxI7jluajY2ycTtx78lSGWp7m6HQ9PUwgGBNX6gMwIDAQABo4IB
wDCCAbwwFAYDVR0RBA0wC4IJbG9jYWxob3N0MA4GA1UdDwEB/wQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUhXUQJdAsgFAkGltXcN61y3GpO3swfQYDVR0jBHYwdIAUs4qgorpx8agkedSk
WyU2FR5JyM2hUaRPME0xCzAJBgNVBAYTAlhZMSYwJAYDVQQKDB1QeXRob24gU29m
dHdhcmUgRm91bmRhdGlvbiBDQTEWMBQGA1UEAwwNb3VyLWNhLXNlcnZlcoIJAMst
gJlaaVJbMIGDBggrBgEFBQcBAQR3MHUwPAYIKwYBBQUHMAKGMGh0dHA6Ly90ZXN0
Y2EucHl0aG9udGVzdC5uZXQvdGVzdGNhL3B5Y2FjZXJ0LmNlcjA1BggrBgEFBQcw
AYYpaHR0cDovL3Rlc3RjYS5weXRob250ZXN0Lm5ldC90ZXN0Y2Evb2NzcC8wQwYD
VR0fBDwwOjA4oDagNIYyaHR0cDovL3Rlc3RjYS5weXRob250ZXN0Lm5ldC90ZXN0
Y2EvcmV2b2NhdGlvbi5jcmwwDQYJKoZIhvcNAQELBQADggGBAJXzVrvVjHC90d7a
Y7Ap19tgJ9ZZ/WEbMMbQXXN9NOFo4yimieZgvYnTDvRyrXJ2+IYh/XU8+G2+nATh
ggNpbK7QVbpe8sr1D47W2Y3IVkb0+Kx0Khl7jkdwH/v7vWkCoaVKbiEcBBQVVb+/
JEPIFwO+Pizq28ivHf1S39YVSZ7CRGnv8UVDg7IezxQcEz/+nHHL5xsYVjanr0Tx
C6F5REb5Q0Yp2LDKSU1lYNP2jnS8Yp4ejUspmrQN8KJ3WzTkES+nJcXlB3YSrr51
cxXkCn1TOFY/eW1uyu2Aq1btfosc5+PUYjAicOcpsgM8/vo98DbATRGimdMpMSe4
xbgVozxPm3NeK7L7y/11R7gXvSHY5sG5/3OB2CUIbQheHKWDUN5n5trQjlrT8iqx
P7iAIQdqcRVtBetRs1mN1BVGfgKoEwEWmb0DzHBxKiMWeK/R1QGdBLRjk5oEOpIu
5n5zk6X+UJu9DupUhm985RR3/sIoWkoO1y2M6e1hKbJT/2wEvA==
-----END CERTIFICATE-----

 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_get_server_certificate_timeout (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52435)

 server:  bad connection attempt from ('127.0.0.1', 52435):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:969)
ok
test_makefile_close (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52437)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_non_blocking_connect_ex (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52439)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_non_blocking_handshake (test.test_ssl.SimpleBackgroundTests) ...  server:  new connection from ('127.0.0.1', 52441)

Needed 2 calls to do_handshake() to establish session.
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_PROTOCOL_TLS (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options ... 
 PROTOCOL_TLS->PROTOCOL_TLS CERT_NONE
 PROTOCOL_TLSv1->PROTOCOL_TLS CERT_NONE
 PROTOCOL_TLS->PROTOCOL_TLS CERT_OPTIONAL
 PROTOCOL_TLSv1->PROTOCOL_TLS CERT_OPTIONAL
 PROTOCOL_TLS->PROTOCOL_TLS CERT_REQUIRED
 PROTOCOL_TLSv1->PROTOCOL_TLS CERT_REQUIRED
 PROTOCOL_TLS->PROTOCOL_TLS CERT_NONE
 {PROTOCOL_TLSv1->PROTOCOL_TLS} CERT_NONE
ok
test_alpn_protocols (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52459)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 server:  new connection from ('127.0.0.1', 52461)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 server:  new connection from ('127.0.0.1', 52463)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 server:  new connection from ('127.0.0.1', 52465)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
ok
test_asyncore_server (test.test_ssl.ThreadedTests)
Check the example asyncore integration. ... 
 server:  new connection from 127.0.0.1:52467
 client:  sending b'FOO\n'...
 server:  read b'FOO\n' from client
 client:  read b'foo\n'
 client:  closing connection.
 client:  connection closed.
 cleanup: stopping server.
 server:  read b'over\n' from client
 cleanup: joining server thread.
 server:  closed connection <ssl.SSLSocket [closed] fd=-1, family=AF_INET, type=SOCK_STREAM, proto=0>
 server:  read b'' from client
 cleanup: successfully joined.
ok
test_check_hostname (test.test_ssl.ThreadedTests) ... 
 server:  new connection from ('127.0.0.1', 52469)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52471)

 server:  bad connection attempt from ('127.0.0.1', 52471):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:969)
ok
test_check_hostname_idn (test.test_ssl.ThreadedTests) ... 
 server:  new connection from ('127.0.0.1', 52474)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52476)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52478)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52480)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52482)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52484)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52486)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52488)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52490)

 server:  bad connection attempt from ('127.0.0.1', 52490):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:969)
ok
test_compression (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52492)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 got compression: None
ok
test_compression_disabled (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52494)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
ok
test_crl_check (test.test_ssl.ThreadedTests) ... 
 server:  new connection from ('127.0.0.1', 52496)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52498)

 server:  bad connection attempt from ('127.0.0.1', 52498):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:969)
 server:  new connection from ('127.0.0.1', 52500)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_default_ecdh_curve (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52502)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
ok
test_dh_params (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52504)
 server: connection cipher is now ('DHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
ok
test_do_handshake_enotconn (test.test_ssl.ThreadedTests) ... ok
test_dual_rsa_ecc (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52506)
 server: connection cipher is now ('ECDHE-ECDSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
ok
test_ecc_cert (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52508)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_ecdh_curve (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52510)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 server:  new connection from ('127.0.0.1', 52512)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 server:  new connection from ('127.0.0.1', 52514)

 server:  bad connection attempt from ('127.0.0.1', 52514):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: NO_SUITABLE_KEY_SHARE] no suitable key share (_ssl.c:969)
ok
test_echo (test.test_ssl.ThreadedTests)
Basic test of an SSL client connecting to a server ... 
 server:  new connection from ('127.0.0.1', 52516)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
 server:  new connection from ('127.0.0.1', 52518)

 server:  bad connection attempt from ('127.0.0.1', 52518):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL] called a function you should not call (_ssl.c:969)
 server:  new connection from ('127.0.0.1', 52520)

 server:  bad connection attempt from ('127.0.0.1', 52520):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:969)
 server:  new connection from ('127.0.0.1', 52522)

 server:  bad connection attempt from ('127.0.0.1', 52522):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL] called a function you should not call (_ssl.c:969)
ok
test_getpeercert (test.test_ssl.ThreadedTests) ... 
{'OCSP': ('http://testca.pythontest.net/testca/ocsp/',),
 'caIssuers': ('http://testca.pythontest.net/testca/pycacert.cer',),
 'crlDistributionPoints': ('http://testca.pythontest.net/testca/revocation.crl',),
 'issuer': ((('countryName', 'XY'),),
            (('organizationName', 'Python Software Foundation CA'),),
            (('commonName', 'our-ca-server'),)),
 'notAfter': 'Oct 28 14:23:16 2037 GMT',
 'notBefore': 'Aug 29 14:23:16 2018 GMT',
 'serialNumber': 'CB2D80995A69525C',
 'subject': ((('countryName', 'XY'),),
             (('localityName', 'Castle Anthrax'),),
             (('organizationName', 'Python Software Foundation'),),
             (('commonName', 'localhost'),)),
 'subjectAltName': (('DNS', 'localhost'),),
 'version': 3}
Connection cipher is ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256).
ok
test_getpeercert_enotconn (test.test_ssl.ThreadedTests) ... ok
test_handshake_timeout (test.test_ssl.ThreadedTests) ... ok
test_hostname_checks_common_name (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52529)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52531)

 server:  bad connection attempt from ('127.0.0.1', 52531):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:969)
ok
test_min_max_version_mismatch (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52533)

 server:  bad connection attempt from ('127.0.0.1', 52533):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:969)
ok
test_min_max_version_sslv3 (test.test_ssl.ThreadedTests) ... skipped 'SSLv3 is not available.'
test_min_max_version_tlsv1_1 (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52535)
 server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
ok
test_min_max_version_tlsv1_2 (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52537)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
ok
test_no_shared_ciphers (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52539)

 server:  bad connection attempt from ('127.0.0.1', 52539):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:969)
ok
test_nonblocking_send (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52541)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
Test server failure:
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2491, in run
    self.write(msg.lower())
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2410, in write
    return self.sslconn.write(bytes)
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1148, in write
    return self._sslobj.write(data)
 ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2286)
ok
test_npn_protocols (test.test_ssl.ThreadedTests) ... ok
test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options ... skipped 'SSLv2 is not available.'
test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options ... skipped 'SSLv3 is not available.'
test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1 server with various client options ... 
 PROTOCOL_TLSv1->PROTOCOL_TLSv1 CERT_NONE
 PROTOCOL_TLSv1->PROTOCOL_TLSv1 CERT_OPTIONAL
 PROTOCOL_TLSv1->PROTOCOL_TLSv1 CERT_REQUIRED
 {PROTOCOL_TLS->PROTOCOL_TLSv1} CERT_NONE
ok
test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options. ... 
 PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_1 CERT_NONE
 {PROTOCOL_TLS->PROTOCOL_TLSv1_1} CERT_NONE
 PROTOCOL_TLSv1_1->PROTOCOL_TLS CERT_NONE
 {PROTOCOL_TLSv1_2->PROTOCOL_TLSv1_1} CERT_NONE
 {PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_2} CERT_NONE
ok
test_protocol_tlsv1_2 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.2 server with various client options. ... 
 PROTOCOL_TLSv1_2->PROTOCOL_TLSv1_2 CERT_NONE
 {PROTOCOL_TLS->PROTOCOL_TLSv1_2} CERT_NONE
 PROTOCOL_TLSv1_2->PROTOCOL_TLS CERT_NONE
 {PROTOCOL_TLSv1->PROTOCOL_TLSv1_2} CERT_NONE
 {PROTOCOL_TLSv1_2->PROTOCOL_TLSv1} CERT_NONE
 {PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_2} CERT_NONE
 {PROTOCOL_TLSv1_2->PROTOCOL_TLSv1_1} CERT_NONE
ok
test_read_write_after_close_raises_valuerror (test.test_ssl.ThreadedTests) ... ok
test_recv_send (test.test_ssl.ThreadedTests)
Test recv(), send() and friends. ... 
 server:  new connection from ('127.0.0.1', 52577)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_recv_zero (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52580)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_rude_shutdown (test.test_ssl.ThreadedTests)
A brutal shutdown of an SSL server should raise an OSError ... ok
test_selected_alpn_protocol (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52584)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
ok
test_selected_alpn_protocol_if_server_uses_alpn (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52586)
 client:  sending b'FOO\n'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  sending b'FOO\n'...
 client:  read b'foo\n'
 client:  closing connection.
ok
test_sendfile (test.test_ssl.ThreadedTests) ... ok
test_server_accept (test.test_ssl.ThreadedTests) ... ok
test_session (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52592)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
 server:  new connection from ('127.0.0.1', 52594)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
 server:  new connection from ('127.0.0.1', 52596)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
 server:  new connection from ('127.0.0.1', 52598)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
ok
test_session_handling (test.test_ssl.ThreadedTests) ... ok
test_shared_ciphers (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52604)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_sni_callback (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52606)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52608)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52610)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_sni_callback_alert (test.test_ssl.ThreadedTests) ... ok
test_sni_callback_raising (test.test_ssl.ThreadedTests) ... ok
test_sni_callback_wrong_return_type (test.test_ssl.ThreadedTests) ... ok
test_socketserver (test.test_ssl.ThreadedTests)
Using socketserver to create and manage SSL connections. ... 
 server (('127.0.0.1', 52617):52617 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)):
   [26/Apr/2021 11:43:19] "GET /keycert.pem HTTP/1.1" 200 -
 client: read 4058 bytes from remote server '<HTTPSServerThread <HTTPSServer 1.0.0.127.in-addr.arpa:52617>>'
stopping HTTPS server
joining HTTPS thread
ok
test_ssl_cert_verify_error (test.test_ssl.ThreadedTests) ... 
 server:  new connection from ('127.0.0.1', 52621)

 server:  bad connection attempt from ('127.0.0.1', 52621):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:969)
ok
test_starttls (test.test_ssl.ThreadedTests)
Switching from clear text to encrypted and back again. ... 
 client:  sending b'msg 1'...
 server:  new connection from ('127.0.0.1', 52623)
 server: read b'msg 1' (unencrypted), sending back b'msg 1' (unencrypted)...
 client:  read b'msg 1' from server
 client:  sending b'MSG 2'...
 server: read b'MSG 2' (unencrypted), sending back b'msg 2' (unencrypted)...
 client:  read b'msg 2' from server
 client:  sending b'STARTTLS'...
 server: read STARTTLS from client, sending OK...
 client:  read b'ok' from server, starting TLS...
 client:  sending b'MSG 3'...
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server: read b'MSG 3' (encrypted), sending back b'msg 3' (encrypted)...
 client:  read b'msg 3' from server
 client:  sending b'msg 4'...
 server: read b'msg 4' (encrypted), sending back b'msg 4' (encrypted)...
 client:  read b'msg 4' from server
 client:  sending b'ENDTLS'...
 server: read ENDTLS from client, sending OK...
 client:  read b'ok' from server, ending TLS...
 client:  sending b'msg 5'...
 server: connection is now unencrypted...
 server: read b'msg 5' (unencrypted), sending back b'msg 5' (unencrypted)...
 client:  read b'msg 5' from server
 client:  sending b'msg 6'...
 server: read b'msg 6' (unencrypted), sending back b'msg 6' (unencrypted)...
 client:  read b'msg 6' from server
 client:  closing connection.
 server: client closed connection
ok
test_tls1_3 (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52625)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_tls_unique_channel_binding (test.test_ssl.ThreadedTests)
Test tls-unique channel binding. ... 
 server:  new connection from ('127.0.0.1', 52627)
 got channel binding data: b'\xb6\xc4\x94=\xb1\xc0\xe1\x05\xbd\x803\xd1\xec\x14,\x95\x8d\xbe!\xbf\xa6\x93\x06)\xc0(U\r\x8d\xdcA\xe9\xa2\xef\xae*6\xa8\xb5~;\x8f\xd9\xa6\x141x\xa2'
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
 server:  new connection from ('127.0.0.1', 52628)
got another channel binding data: b'N1\xb3OAX\xaa\x05dD/~\x8a\xcbM\xf3\x1b\x1a<\x98:\xb9\x80\xf6b\xe3\x1a\x0e\x9e\xf6\x87\xde\xfc\xfc\xc4\x93t\x90a\xb7\xa6O\xdf\xcc\x10\xdf?y'
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
ok
test_version_basic (test.test_ssl.ThreadedTests)
Basic tests for SSLSocket.version(). ... ok
test_wrong_cert_tls12 (test.test_ssl.ThreadedTests)
Connecting when the server rejects the client's certificate ...  server:  new connection from ('127.0.0.1', 52632)

SSLError is SSLError(1, '[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:969)')

 server:  bad connection attempt from ('127.0.0.1', 52632):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:969)
ok
test_wrong_cert_tls13 (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 52634)

SSLError is SSLError(1, '[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2438)')

 server:  bad connection attempt from ('127.0.0.1', 52634):
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2347, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 518, in wrap_socket
    return self.sslsocket_class._create(
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1070, in _create
    self.do_handshake()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:969)
ok
test_bpo37428_pha_cert_none (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_no_pha_client (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_no_pha_server (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_not_tls13 (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_optional (test.test_ssl.TestPostHandshakeAuth) ... 
ok
test_pha_optional_nocert (test.test_ssl.TestPostHandshakeAuth) ... 
ok
test_pha_required (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth) ...  server:  new connection from ('127.0.0.1', 52650)
 client cert is None
 client did not provide a cert
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
TLS: (<ssl.SSLSocket fd=7, family=AF_INET, type=SOCK_STREAM, proto=0, laddr=('127.0.0.1', 52649), raddr=('127.0.0.1', 52650)>, 'write', TLSVersion.TLSv1_3, _TLSContentType.ALERT, _TLSAlertType.CERTIFICATE_REQUIRED, b'\x02t')
TLS: (<ssl.SSLSocket fd=6, family=AF_INET, type=SOCK_STREAM, proto=0, laddr=('127.0.0.1', 52650), raddr=('127.0.0.1', 52649)>, 'read', TLSVersion.TLSv1_3, _TLSContentType.ALERT, _TLSAlertType.CERTIFICATE_REQUIRED, b'\x02t')
Test server failure:
Traceback (most recent call last):
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2427, in run
    msg = self.read()
   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2404, in read
    return self.sslconn.read()
   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1131, in read
    return self._sslobj.read(len)
 ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2438)
ok
test_pha_setter (test.test_ssl.TestPostHandshakeAuth) ... ok
test_keylog_defaults (test.test_ssl.TestSSLDebug) ... ok
test_keylog_env (test.test_ssl.TestSSLDebug) ... skipped 'test is not compatible with ignore_environment'
test_keylog_filename (test.test_ssl.TestSSLDebug) ... ok
test_msg_callback (test.test_ssl.TestSSLDebug) ... ok
test_msg_callback_deadlock_bpo43577 (test.test_ssl.TestSSLDebug) ... ok
test_msg_callback_tls12 (test.test_ssl.TestSSLDebug) ... ok
test_get_server_certificate_ipv6 (test.test_ssl.NetworkedTests) ... skipped "Resource 'ipv6.google.com' is not available"
test test_ssl failed
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok

======================================================================
ERROR: test_connect_capath (test.test_ssl.SimpleBackgroundTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2045, in test_connect_capath
    s.connect(self.server_addr)
  File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1372, in connect
    self._real_connect(addr, False)
  File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1363, in _real_connect
    self.do_handshake()
  File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1339, in do_handshake
    self._sslobj.do_handshake()
ConnectionResetError: [Errno 54] Connection reset by peer

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

Ran 164 tests in 29.112s

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

----------
messages: 391914
nosy: christian.heimes, pablogsal
priority: normal
severity: normal
status: open
title: test_ssl fails in the macos CI
versions: Python 3.10

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

From report at bugs.python.org  Mon Apr 26 16:59:45 2021
From: report at bugs.python.org (Genaro Camele)
Date: Mon, 26 Apr 2021 20:59:45 +0000
Subject: [New-bugs-announce] [issue43944] Processes in Python 3.9 exiting
 with code 1 when It's created inside a ThreadPoolExecutor
Message-ID: <1619470785.38.0.461987263008.issue43944@roundup.psfhosted.org>


New submission from Genaro Camele <genarocamele at hotmail.com>:

I've a piece of code that submits a task to a [ThreadPoolExecutor][1] which starts a [Process][2]. I've realised that in Python 3.8 that Process finished with exit code `0`. But I've updated Python to the 3.9 version and this started to finishing with exit code `1`! Even when the Process executes an empty task.

Here's a minimal example:

```python
from multiprocessing import Process
from concurrent.futures import ThreadPoolExecutor


def some_task():
    pass


def execute_error():
    p = Process(target=some_task)
    p.start()
    p.join()
    print(p.exitcode)  # This is always 1 on a ThreadPoolExecutor!!!


executor = ThreadPoolExecutor(max_workers=4)
executor.submit(execute_error)
# execute_error()  # IMPORTANT: this works correctly (exit 0)
```

My versions:

```
Ubuntu 21.04
Python 3.9.4
```

**Note** that if `__execute_error` is called outside the ThreadPoolExecutor it works correctly.
Running on Python 3.8.6 exitcode = 0 too.


  [1]: https://docs.python.org/3/library/concurrent.futures.html#threadpoolexecutor
  [2]: https://docs.python.org/3.9/library/multiprocessing.html#multiprocessing.Process

----------
messages: 391985
nosy: Genarito
priority: normal
severity: normal
status: open
title: Processes in Python 3.9 exiting with code 1 when It's created inside a ThreadPoolExecutor
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 26 19:04:32 2021
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 26 Apr 2021 23:04:32 +0000
Subject: [New-bugs-announce] [issue43945] [Enum] standardize format()
 behavior
Message-ID: <1619478272.35.0.783754187217.issue43945@roundup.psfhosted.org>


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

Currently, an enum with a mixed-in data type, such as IntEnum, will use that data type's `__format__` -- unless the user provides their own `__str__`, in which case the `str()` of the enum member will be used in the `format()` call.

This behavior will be deprecated in 3.10, and in 3.12 the default `__format__` will use the default `__str__`, which is the standard behavior for Python objects

For those that were relying on, for example,

    class Color(IntEnum):
        RED = 1

    f'{Color.RED}' # -> '2'

They will need to add ":d" to ensure the integer output:

    f'{Color.RED:d}'

This change does work now.

----------
assignee: ethan.furman
messages: 391995
nosy: ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: [Enum] standardize format() behavior
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Apr 26 20:33:02 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 27 Apr 2021 00:33:02 +0000
Subject: [New-bugs-announce] [issue43946] unpickling a subclass of list
 fails when it implements its own extend method
Message-ID: <1619483582.32.0.0403635127136.issue43946@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

The changes from https://bugs.python.org/issue29368 are causing a subclass of list trouble:

```
class FieldList(list):
    ...
    def extend(...): ...
```

FieldList has its own extend and append methods that implement additional checks.  As it is a list subclass, the new `PyList_CheckExact()` from the afformentioned issue's https://github.com/python/cpython/commit/f89fdc29937139b55dd68587759cadb8468d0190 where it used to be a `PyList_Check()` in 3.6 and earlier is causing the unpickling code to call the instance `.extend()` method instead of internally using `PyList_SetSlice()` at the C level.

Calling .extend() naturally fails at this point as __setstate__ hasn't yet been called so the FieldList instance is uninitialized.

Here's the code in question https://github.com/google/protorpc/blob/master/protorpc/messages.py#L1126

It used it work.  3.7 broke it.  What was unpicklable is now not.

To work around this logic would be needed in the extend (and append) methods to check if they're being called on an uninitialized instance.  That seems unreasonable.

_[credit to my colleague Richard L. for the diagnosis]_

----------
components: Extension Modules, Library (Lib)
keywords: 3.7regression
messages: 392008
nosy: gregory.p.smith, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: unpickling a subclass of list fails when it implements its own extend method
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/issue43946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:13:48 2021
From: report at bugs.python.org (Dan Snider)
Date: Tue, 27 Apr 2021 02:13:48 +0000
Subject: [New-bugs-announce] [issue43947] lambdas stored with assignment
 expressions are unoptimized
Message-ID: <1619489628.98.0.0361601429976.issue43947@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

>>> import dis
>>> @dis.dis
... def funcdef(k): return k in {None}                          ...                                                               2           0 LOAD_FAST                0 (k)
              2 LOAD_CONST               1 (frozenset({None}))                4 COMPARE_OP               6 (in)                               6 RETURN_VALUE
>>> regass = lambda k: k in {None}
>>> dis.dis(regass)
  1           0 LOAD_FAST                0 (k)
              2 LOAD_CONST               1 (frozenset({None}))
              4 COMPARE_OP               6 (in)
              6 RETURN_VALUE                                    >>> dis.dis(walrus:=lambda k: k in {None})
  1           0 LOAD_FAST                0 (k)
              2 LOAD_CONST               0 (None)
              4 BUILD_SET                1
              6 COMPARE_OP               6 (in)
              8 RETURN_VALUE

As the third example demonstrates, the code for the anonymous function assigned to walrus by an assignment expression isn't receiving the relatively recent frozenset optimization.

----------
messages: 392015
nosy: bup
priority: normal
severity: normal
status: open
title: lambdas stored with assignment expressions are unoptimized
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr 27 03:53:25 2021
From: report at bugs.python.org (Tzu-ping Chung)
Date: Tue, 27 Apr 2021 07:53:25 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue43948=5D_sysconfig?=
 =?utf-8?q?=E2=80=99s_osx=5Fframework=5Fuser_puts_headers_in_different_loc?=
 =?utf-8?q?ations_from_distutils?=
Message-ID: <1619510005.78.0.165065669518.issue43948@roundup.psfhosted.org>


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

When built in framework mode on macOS, distutils puts user-site headers under `{userbase}/include/python{py_version_short}{abiflags}`:

>>> import sys
>>> print(sys.platform, sys._framework)
darwin Python
>>> from distutils.dist import Distribution
>>> c = Distribution().get_command_obj('install')
>>> c.user = True
>>> c.finalize_options()
>>> print(c.install_headers)
/Users/uranusjr/Library/Python/3.9/include/python3.9/UNKNOWN

But sysconfig lacks the `pythonX.Y` part:

>>> import sysconfig
>>> print(sysconfig.get_path('include', scheme='osx_framework_user'))
/Users/uranusjr/Library/Python/3.9/include

This is inconsistent to all other schemes, such as `posix_user` (tested on the `python:3.9-slim` OCI image):

>>> import sys
>>> print(sys.platform, sys._framework)
linux
>>> from distutils.dist import Distribution
>>> c = Distribution().get_command_obj('install')
>>> c.user = True
>>> c.finalize_options()
>>> print(c.install_headers)
/root/.local/include/python3.9/UNKNOWN
>>> import sysconfig
>>> print(sysconfig.get_path('include', scheme='posix_user'))
/root/.local/include/python3.9

Note that the paths on `posix_user` only differs by one component (`UNKNOWN`, which is the distribution name), but `osx_framework_user` differs by two.

----------
components: Library (Lib)
messages: 392037
nosy: uranusjr
priority: normal
severity: normal
status: open
title: sysconfig?s osx_framework_user puts headers in different locations from distutils
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/issue43948>
_______________________________________

From report at bugs.python.org  Tue Apr 27 03:57:58 2021
From: report at bugs.python.org (junpengruan)
Date: Tue, 27 Apr 2021 07:57:58 +0000
Subject: [New-bugs-announce] [issue43949] binascii.Error raised in smtplib
 when initial_response_ok=False
Message-ID: <1619510278.38.0.0405436447685.issue43949@roundup.psfhosted.org>


New submission from junpengruan <632077280 at qq.com>:

Hi
I think there is a bug when initial_response_ok=False and using AUTH PLAIN, the server will response like:
------------------
C: AUTH PLAIN
S: 334 ok. go on
------------------
and it's not base64 encoding, while in the auth() it will base64 decode the resp(here is "ok, go on") which will cause a binascii.Error:

Traceback (most recent call last):
  File "/usr/lib/python3.6/smtplib.py", line 644, in auth
    challenge = base64.decodebytes(resp)
  File "/usr/lib/python3.6/base64.py", line 553, in decodebytes
    return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

I am using Magic Winmail Server2.4(build 0530) as a SMTP server, which appears dont support initial_response, so I set initial_response_ok=False and got this Error. 
currently I catch this error and ignore it to evade program failed, it works fine. Is there better way to fix this problem?

Thanks!

----------
components: email
messages: 392039
nosy: barry, junpengruan, r.david.murray
priority: normal
severity: normal
status: open
title: binascii.Error raised in smtplib when initial_response_ok=False
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/issue43949>
_______________________________________

From report at bugs.python.org  Tue Apr 27 06:58:38 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Apr 2021 10:58:38 +0000
Subject: [New-bugs-announce] [issue43950] Include column offsets for
 bytecode instructions
Message-ID: <1619521118.33.0.233805842394.issue43950@roundup.psfhosted.org>


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

If we could include column offsets from the AST nodes for every bytecode instructions we could leverage these to offer much better tracebacks and a lot more information to debuggers and similar tools. For instance, in an expression such as:

z['aaaaaa']['bbbbbb']['cccccc']['dddddd].sddfsdf.sdfsdf

where one of these elements is None, we could tell exactly what of these pieces is the actual None and we could do some cool highlighting on tracebacks.

Similarly, coverage tools and debuggers could also make this distinction and therefore could offer reports with more granularity.

The cost is not 0: it would be two integers per bytecode instruction, but I think it may be worth the effort.

----------
messages: 392054
nosy: Mark.Shannon, pablogsal
priority: normal
severity: normal
status: open
title: Include column offsets for bytecode instructions

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

From report at bugs.python.org  Tue Apr 27 07:06:19 2021
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 27 Apr 2021 11:06:19 +0000
Subject: [New-bugs-announce] [issue43951] Two minor fixes for C module object
Message-ID: <1619521579.23.0.324189494651.issue43951@roundup.psfhosted.org>


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

While working on another issue, I noticed two minor nits in the C implementation of the module object.  Both are related to getting a module's name.

--

First, the C function module_dir() (module.__dir__) starts by ensuring the module dict is valid.  If the module dict is invalid, it wants to format an exception using the name of the module, which it gets from PyModule_GetName().  However, PyModule_GetName() gets the name of the module from the dict.  So getting the name in this circumstance will never succeed.

When module_dir() wants to format the error but can't get the name, it knows that PyModule_GetName() must have already raised an exception.  So it leaves that exception alone and returns an error.  The end result is that the exception raised here is kind of useless and misleading: dir(module) on a module with no __dict__ raises SystemError("nameless module").  I changed the code to actually raise the exception it wanted to raise, just without a real module name: TypeError("<module>.__dict__ is not a dictionary").  This seems more useful, and would do a better job putting the programmer who encountered this on the right track of figuring out what was going on.

--

Second, the C API function PyModule_GetNameObject() checks to see if the module has a dict.  If m->md_dict is not NULL, it calls _PyDict_GetItemIdWithError().  However, it's possible for m->md_dict to be None.  And if you call _PyDict_GetItemIdWithError(Py_None, ...) it will *crash*.

Unfortunately, this crash was due to my own bug in the other branch.  Fixing my code made the crash go away.  I assert that this is still possible at the API level.

The fix is easy: add a PyDict_Check() to PyModule_GetNameObject().

Unfortunately, I don't know how to add a unit test for this.  Having changed module_dir() above, I can't find any other interfaces callable from Python that eventually call PyModule_GetNameObject().  So I don't know how to trick the runtime into reproducing this error.

----------
assignee: larry
components: Interpreter Core
messages: 392055
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Two minor fixes for C module object
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 27 07:45:15 2021
From: report at bugs.python.org (anon01)
Date: Tue, 27 Apr 2021 11:45:15 +0000
Subject: [New-bugs-announce] [issue43952] Multiprocessing UNIX socket
 connection: client freeze if authkey is an empty byte string
Message-ID: <1619523915.52.0.163488043908.issue43952@roundup.psfhosted.org>


New submission from anon01 <swsfinoa at sharklasers.com>:

When I run this code (on a UNIX system with temporary directory `/tmp/`):

```
from multiprocessing import connection
import threading
key=b"1"

def run():
    c=connection.Client("/tmp/xxx", authkey=key)
    c.send("data")

l=connection.Listener("/tmp/xxx", authkey=key)
threading.Thread(target=run).start()
c=l.accept()
print("receive", c.recv())
```

it prints out "receive data" normally.

However, in the special case that `key=b""` the doesn't print anything, and can only be interrupted with Ctrl+C.

`key=None` doesn't have that issue.

Note that this issue does happen when the client uses the key `b""` and the server uses the key `None`, but the program works normally if the reverse situation.

Python version: Python 3.9.3.

----------
components: Library (Lib)
messages: 392056
nosy: anon01
priority: normal
severity: normal
status: open
title: Multiprocessing UNIX socket connection: client freeze if authkey is an empty byte string
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 27 07:54:00 2021
From: report at bugs.python.org (Sergei Lebedev)
Date: Tue, 27 Apr 2021 11:54:00 +0000
Subject: [New-bugs-announce] [issue43953] InitVar should not be available on
 a @dataclass-decorated class
Message-ID: <1619524440.38.0.385093329161.issue43953@roundup.psfhosted.org>


New submission from Sergei Lebedev <sergei.a.lebedev at gmail.com>:

Motivating example:

>>> @dataclass
... class A:
...   x: InitVar[int] = 0
...   y: int = 1
... 
>>> a = A()
>>> a.x
0
>>> a.y
1

PEP-557 does not specify if fields annotated with InitVar[...] are available on the resulting dataclass. However, they are not part of the dataclass structure and are only used for __*init__ generation, so perhaps they shouldn't be? Wdyt?

----------
components: Library (Lib)
messages: 392058
nosy: eric.smith, superbobry
priority: normal
severity: normal
status: open
title: InitVar should not be available on a @dataclass-decorated class
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/issue43953>
_______________________________________

From report at bugs.python.org  Tue Apr 27 08:21:08 2021
From: report at bugs.python.org (Julien Palard)
Date: Tue, 27 Apr 2021 12:21:08 +0000
Subject: [New-bugs-announce] [issue43954] Possible missing word on unittest
 doc
Message-ID: <1619526068.5.0.0964164100817.issue43954@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In https://docs.python.org/3/library/unittest.html I see:

> Note that you need to the top level directory too.

Trying to guess, the missing word may be "specify":

> Changed in version 3.4: Test discovery supports namespace packages for start directory. Note that you need to specify the top level directory too. (e.g. python -m unittest discover -s root/namespace -t root).

Am I right?

----------
assignee: docs at python
components: Documentation
messages: 392060
nosy: docs at python, mdk, methane
priority: normal
severity: normal
status: open
title: Possible missing word on unittest doc
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/issue43954>
_______________________________________

From report at bugs.python.org  Tue Apr 27 13:03:07 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Tue, 27 Apr 2021 17:03:07 +0000
Subject: [New-bugs-announce] [issue43955] Test Failures on Windows 10
Message-ID: <1619542987.31.0.479223769103.issue43955@roundup.psfhosted.org>


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

Recent test failures have been noticed on Windows 10. The full test log has been attached. The tests test_distutils, test_pdb, test_signal and test_threading require a little bit of attention since there seems to be some kind of error.

----------
components: Windows
files: tests_log.txt
messages: 392104
nosy: Guido.van.Rossum, Mark.Shannon, christian.heimes, corona10, erlendaasland, gvanrossum, pablogsal, paul.moore, serhiy.storchaka, shihai1991, shreyanavigyan, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Test Failures on Windows 10
versions: Python 3.10
Added file: https://bugs.python.org/file49995/tests_log.txt

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

From report at bugs.python.org  Tue Apr 27 13:57:00 2021
From: report at bugs.python.org (Jouke Witteveen)
Date: Tue, 27 Apr 2021 17:57:00 +0000
Subject: [New-bugs-announce] [issue43956] C-API: Incorrect default value for
 Py_SetProgramName
Message-ID: <1619546220.77.0.781822360652.issue43956@roundup.psfhosted.org>


New submission from Jouke Witteveen <j.witteveen at gmail.com>:

The default program name is hardcoded in Python/initconfig.c:config_init_program_name. It is "python" on Windows, and "python3" elsewhere. The documentation currently suggests that it is "python" everywhere.

Additionally, the documentation currently says:

> The argument should point to a zero-terminated wide character string in static storage whose contents will not change for the duration of the program?s execution.

The code, however, duplicates the string, so I am not sure this is true.

----------
assignee: docs at python
components: Documentation
messages: 392113
nosy: docs at python, joukewitteveen
priority: normal
pull_requests: 24356
severity: normal
status: open
title: C-API: Incorrect default value for Py_SetProgramName
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/issue43956>
_______________________________________

From report at bugs.python.org  Tue Apr 27 15:11:08 2021
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 27 Apr 2021 19:11:08 +0000
Subject: [New-bugs-announce] [issue43957] [Enum] update __contains__ to
 return True for valid values
Message-ID: <1619550668.75.0.616141985831.issue43957@roundup.psfhosted.org>


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

In 3.12 `__contains__` will check for both members and values:

    Color.RED in Color  --> True
    1 in Color          --> True
    'RED' in Color      --> False

Add DeprecationWarning for now.

----------
assignee: ethan.furman
messages: 392122
nosy: ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: [Enum] update __contains__ to return True for valid values
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 27 15:25:40 2021
From: report at bugs.python.org (Paul Moore)
Date: Tue, 27 Apr 2021 19:25:40 +0000
Subject: [New-bugs-announce] [issue43958] Importlib.metadata docs claim
 PackagePath is a Path subclass
Message-ID: <1619551540.42.0.304542326488.issue43958@roundup.psfhosted.org>


New submission from Paul Moore <p.f.moore at gmail.com>:

The importlib.metadata documentation states that the PackagePath class is "a pathlib.Path derived object". This isn't true - it's a PurePath subclass, and in particular it does not have a resolve() method. In fact, it has an undocumented custom locate() method that converts it into a Path object.

I propose changing the documentation to make it clear that it is a PurePath subclass, and explicitly documenting the locate() method.

----------
assignee: docs at python
components: Documentation
messages: 392123
nosy: docs at python, paul.moore
priority: normal
severity: normal
status: open
title: Importlib.metadata docs claim PackagePath is a Path subclass
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 27 16:13:25 2021
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Apr 2021 20:13:25 +0000
Subject: [New-bugs-announce] [issue43959] Improve documentation of
 PyContextVar C-API
Message-ID: <1619554405.65.0.363572398331.issue43959@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

The documentation of the PyContextVar C-API is unclear in a couple of places.

- It's not clear whether PyContextVar_Get() always returns an owned reference also for default values or only if a value was found.
- It's not explicit that "optional" actually means "pass an object reference or NULL".
- The return value of PyContextVar_Set() is not explained.

----------
assignee: docs at python
components: Documentation
messages: 392128
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: Improve documentation of PyContextVar C-API
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/issue43959>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:01:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2021 21:01:37 +0000
Subject: [New-bugs-announce] [issue43960] test_pdb fails when only some
 tests are run
Message-ID: <1619557297.65.0.395512110368.issue43960@roundup.psfhosted.org>


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

test_pdb fails with the following commands. I tested on Linux, same/similar failure on Windows.

See also bpo-41914: "test_pdb fails".


$ cat bisect 
test.test_pdb.PdbTestCase.test_run_module
test.test_pdb.test_next_until_return_at_return_event
test.test_pdb.test_pdb_next_command_in_generator_for_loop

$ ./python -m test test_pdb  --matchfile=bisect -v
== CPython 3.10.0a7+ (heads/master:6bd9288b80, Apr 27 2021, 22:16:25) [GCC 11.0.1 20210324 (Red Hat 11.0.1-0)]
== Linux-5.11.15-300.fc34.x86_64-x86_64-with-glibc2.33 little-endian
== cwd: /home/vstinner/python/master/build/test_python_7720?
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.31 Run tests sequentially
0:00:00 load avg: 1.31 [1/1] test_pdb
test_run_module (test.test_pdb.PdbTestCase) ... ok
test_next_until_return_at_return_event (test.test_pdb)
Doctest: test.test_pdb.test_next_until_return_at_return_event ... ok
test_pdb_next_command_in_generator_for_loop (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_in_generator_for_loop ... FAIL

======================================================================
FAIL: test_pdb_next_command_in_generator_for_loop (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_in_generator_for_loop
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/doctest.py", line 2205, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_next_command_in_generator_for_loop
  File "/home/vstinner/python/master/Lib/test/test_pdb.py", line 1182, in test_pdb_next_command_in_generator_for_loop

----------------------------------------------------------------------
File "/home/vstinner/python/master/Lib/test/test_pdb.py", line 1195, in test.test_pdb.test_pdb_next_command_in_generator_for_loop
Failed example:
    with PdbTestInput(['break test_gen',
                       'continue',
                       'next',
                       'next',
                       'next',
                       'continue']):
        test_function()
Expected:
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[1]>(3)test_function()
    -> for i in test_gen():
    (Pdb) break test_gen
    Breakpoint 1 at <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[0]>:1
    (Pdb) continue
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[0]>(2)test_gen()
    -> yield 0
    (Pdb) next
    value 0
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[0]>(3)test_gen()
    -> return 1
    (Pdb) next
    Internal StopIteration: 1
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[1]>(3)test_function()
    -> for i in test_gen():
    (Pdb) next
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[1]>(5)test_function()
    -> x = 123
    (Pdb) continue
Got:
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[1]>(3)test_function()
    -> for i in test_gen():
    (Pdb) break test_gen
    Breakpoint 2 at <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[0]>:1
    (Pdb) continue
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[0]>(2)test_gen()
    -> yield 0
    (Pdb) next
    value 0
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[0]>(3)test_gen()
    -> return 1
    (Pdb) next
    Internal StopIteration: 1
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[1]>(3)test_function()
    -> for i in test_gen():
    (Pdb) next
    > <doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[1]>(5)test_function()
    -> x = 123
    (Pdb) continue


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

Ran 3 tests in 0.186s

FAILED (failures=1)
test test_pdb failed
test_pdb failed

== Tests result: FAILURE ==

1 test failed:
    test_pdb

Total duration: 480 ms
Tests result: FAILURE

----------
components: Tests
messages: 392131
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_pdb fails when only some tests are run
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 27 17:25:51 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2021 21:25:51 +0000
Subject: [New-bugs-announce] [issue43961]
 test_logging.test_namer_rotator_inheritance() logs a logging error
Message-ID: <1619558751.24.0.0962393290712.issue43961@roundup.psfhosted.org>


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

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\master>python -m test test_logging -m test_namer_rotator_inheritance
Running Debug|x64 interpreter...
0:00:00 Run tests sequentially
0:00:00 [1/1] test_logging
--- Logging error ---
Traceback (most recent call last):
  File "C:\vstinner\python\master\lib\logging\handlers.py", line 74, in emit
    self.doRollover()
  File "C:\vstinner\python\master\lib\logging\handlers.py", line 179, in doRollover
    self.rotate(self.baseFilename, dfn)
  File "C:\vstinner\python\master\lib\logging\handlers.py", line 117, in rotate
    self.rotator(source, dest)
  File "C:\vstinner\python\master\lib\test\test_logging.py", line 5222, in rotator
    os.rename(source, dest + ".rotated")
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\\Users\\vstinner\\AppData\\Local\\Temp\\test_logging-2-tj71b
t8k.log' -> 'C:\\Users\\vstinner\\AppData\\Local\\Temp\\test_logging-2-tj71bt8k.log.1.test.rotated'
Call stack:
  File "C:\vstinner\python\master\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\vstinner\python\master\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\vstinner\python\master\lib\test\__main__.py", line 2, in <module>
    main()
  File "C:\vstinner\python\master\lib\test\libregrtest\main.py", line 719, in main
    Regrtest().main(tests=tests, **kwargs)
  File "C:\vstinner\python\master\lib\test\libregrtest\main.py", line 641, in main
    self._main(tests, kwargs)
  File "C:\vstinner\python\master\lib\test\libregrtest\main.py", line 694, in _main
    self.run_tests()
  File "C:\vstinner\python\master\lib\test\libregrtest\main.py", line 521, in run_tests
    self.run_tests_sequential()
  File "C:\vstinner\python\master\lib\test\libregrtest\main.py", line 423, in run_tests_sequential
    result = runtest(self.ns, test_name)
  File "C:\vstinner\python\master\lib\test\libregrtest\runtest.py", line 194, in runtest
    return _runtest(ns, test_name)
  File "C:\vstinner\python\master\lib\test\libregrtest\runtest.py", line 154, in _runtest
    result = _runtest_inner(ns, test_name,
  File "C:\vstinner\python\master\lib\test\libregrtest\runtest.py", line 282, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "C:\vstinner\python\master\lib\test\libregrtest\runtest.py", line 246, in _runtest_inner2
    test_runner()
  File "C:\vstinner\python\master\lib\test\support\__init__.py", line 682, in inner
    return func(*args, **kwds)
  File "C:\vstinner\python\master\lib\test\test_logging.py", line 5503, in test_main
    support.run_unittest(*tests)
  File "C:\vstinner\python\master\lib\test\support\__init__.py", line 1082, in run_unittest
    _run_suite(suite)
  File "C:\vstinner\python\master\lib\test\support\__init__.py", line 959, in _run_suite
    result = runner.run(suite)
  File "C:\vstinner\python\master\lib\test\support\testresult.py", line 169, in run
    test(self.result)
  File "C:\vstinner\python\master\lib\unittest\suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "C:\vstinner\python\master\lib\unittest\suite.py", line 122, in run
    test(result)
  File "C:\vstinner\python\master\lib\unittest\suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "C:\vstinner\python\master\lib\unittest\suite.py", line 122, in run
    test(result)
  File "C:\vstinner\python\master\lib\unittest\case.py", line 652, in __call__
    return self.run(*args, **kwds)
  File "C:\vstinner\python\master\lib\unittest\case.py", line 592, in run
    self._callTestMethod(testMethod)
  File "C:\vstinner\python\master\lib\unittest\case.py", line 549, in _callTestMethod
    method()
  File "C:\vstinner\python\master\lib\test\test_logging.py", line 5229, in test_namer_rotator_inheritance
    rh.emit(self.next_rec())
Message: '2'
Arguments: None

== Tests result: SUCCESS ==

1 test OK.

Total duration: 1.1 sec
Tests result: SUCCESS

----------
components: Tests
messages: 392137
nosy: vinay.sajip, vstinner
priority: normal
severity: normal
status: open
title: test_logging.test_namer_rotator_inheritance() logs a logging error
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 27 18:55:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2021 22:55:01 +0000
Subject: [New-bugs-announce] [issue43962] test_interpreters: when
 test_id_type() is run alone, it fails with an assertion error
Message-ID: <1619564101.64.0.809403769547.issue43962@roundup.psfhosted.org>


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

Example on Linux.

$ ./python -m test test_interpreters -m test.test_interpreters.TestInterpreterAttrs.test_id_type
0:00:00 load avg: 1.20 Run tests sequentially
0:00:00 load avg: 1.20 [1/1] test_interpreters
python: Python/pystate.c:561: _PyInterpreterState_IDDecref: Assertion `interp->id_refcount != 0' failed.
Fatal Python error: Aborted

Current thread 0x00007f05eab42740 (most recent call first):
  File "/home/vstinner/python/master/Lib/unittest/case.py", line 549 in _callTestMethod
  File "/home/vstinner/python/master/Lib/unittest/case.py", line 592 in run
  File "/home/vstinner/python/master/Lib/unittest/case.py", line 652 in __call__
  File "/home/vstinner/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/python/master/Lib/test/support/testresult.py", line 169 in run
  File "/home/vstinner/python/master/Lib/test/support/__init__.py", line 959 in _run_suite
  File "/home/vstinner/python/master/Lib/test/support/__init__.py", line 1082 in run_unittest
  File "/home/vstinner/python/master/Lib/test/libregrtest/runtest.py", line 210 in _test_module
  File "/home/vstinner/python/master/Lib/test/libregrtest/runtest.py", line 246 in _runtest_inner2
  File "/home/vstinner/python/master/Lib/test/libregrtest/runtest.py", line 282 in _runtest_inner
  File "/home/vstinner/python/master/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/home/vstinner/python/master/Lib/test/libregrtest/runtest.py", line 194 in runtest
  File "/home/vstinner/python/master/Lib/test/libregrtest/main.py", line 423 in run_tests_sequential
  File "/home/vstinner/python/master/Lib/test/libregrtest/main.py", line 521 in run_tests
  File "/home/vstinner/python/master/Lib/test/libregrtest/main.py", line 694 in _main
  File "/home/vstinner/python/master/Lib/test/libregrtest/main.py", line 641 in main
  File "/home/vstinner/python/master/Lib/test/libregrtest/main.py", line 719 in main
  File "/home/vstinner/python/master/Lib/test/__main__.py", line 2 in <module>
  File "/home/vstinner/python/master/Lib/runpy.py", line 86 in _run_code
  File "/home/vstinner/python/master/Lib/runpy.py", line 196 in _run_module_as_main

Extension modules: _testcapi, _xxsubinterpreters (total: 2)
Abandon (core dumped)


When the whole test case is run, it's fine:

$ ./python -m test test_interpreters -m TestInterpreterAttrs -v
== CPython 3.10.0a7+ (heads/master:6bd9288b80, Apr 27 2021, 22:16:25) [GCC 11.0.1 20210324 (Red Hat 11.0.1-0)]
== Linux-5.11.15-300.fc34.x86_64-x86_64-with-glibc2.33 little-endian
== cwd: /home/vstinner/python/master/build/test_python_16394?
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.39 Run tests sequentially
0:00:00 load avg: 1.39 [1/1] test_interpreters
test_custom_id (test.test_interpreters.TestInterpreterAttrs) ... ok
test_custom_isolated_default (test.test_interpreters.TestInterpreterAttrs) ... skipped 'not ready yet (see bpo-32604)'
test_custom_isolated_explicit (test.test_interpreters.TestInterpreterAttrs) ... ok
test_equality (test.test_interpreters.TestInterpreterAttrs) ... ok
test_id_readonly (test.test_interpreters.TestInterpreterAttrs) ... ok
test_id_type (test.test_interpreters.TestInterpreterAttrs) ... ok
test_isolated_readonly (test.test_interpreters.TestInterpreterAttrs) ... ok
test_main_id (test.test_interpreters.TestInterpreterAttrs) ... ok
test_main_isolated (test.test_interpreters.TestInterpreterAttrs) ... skipped 'not ready yet (see bpo-32604)'
test_subinterpreter_isolated_default (test.test_interpreters.TestInterpreterAttrs) ... skipped 'not ready yet (see bpo-32604)'
test_subinterpreter_isolated_explicit (test.test_interpreters.TestInterpreterAttrs) ... ok

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

Ran 11 tests in 0.159s

OK (skipped=3)

== Tests result: SUCCESS ==

1 test OK.

Total duration: 285 ms
Tests result: SUCCESS

----------
components: Tests
messages: 392145
nosy: eric.snow, nanjekyejoannah, vstinner
priority: normal
severity: normal
status: open
title: test_interpreters: when test_id_type() is run alone, it fails with an assertion error
versions: Python 3.10

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

From report at bugs.python.org  Tue Apr 27 18:58:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2021 22:58:44 +0000
Subject: [New-bugs-announce] [issue43963] test_interpreters has side effects
 on test_signal
Message-ID: <1619564324.1.0.88409924964.issue43963@roundup.psfhosted.org>


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

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\master>type bisect3
test.test_signal.RaiseSignalTest.test_handler
test.test_interpreters.TestInterpreterAttrs.test_main_id
test.test_interpreters.TestInterpreterClose.test_from_sibling

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\master>python -m test test_interpreters test_signal --matchfile=bisect3 -v
Running Debug|x64 interpreter...
== CPython 3.10.0a7+ (heads/master:6bd9288b80, Apr 27 2021, 22:54:42) [MSC v.1928 64 bit (AMD64)]
== Windows-10-10.0.19042-SP0 little-endian
== cwd: C:\vstinner\python\master\build\test_python_5756?
== CPU count: 2
== encodings: locale=cp1252, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/2] test_interpreters
test_main_id (test.test_interpreters.TestInterpreterAttrs) ... ok
test_from_sibling (test.test_interpreters.TestInterpreterClose) ... ok

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

Ran 2 tests in 0.277s

OK
0:00:00 [2/2] test_signal
test_handler (test.test_signal.RaiseSignalTest) ... ERROR

======================================================================
ERROR: test_handler (test.test_signal.RaiseSignalTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\vstinner\python\master\lib\signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object

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

Ran 1 test in 0.004s

FAILED (errors=1)
test test_signal failed
test_signal failed

== Tests result: FAILURE ==

1 test OK.

1 test failed:
    test_signal

Total duration: 689 ms
Tests result: FAILURE

----------
components: Tests
messages: 392147
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_interpreters has side effects on test_signal
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 28 04:39:49 2021
From: report at bugs.python.org (Victor Lazzarini)
Date: Wed, 28 Apr 2021 08:39:49 +0000
Subject: [New-bugs-announce] [issue43964] ctypes CDLL search path issue on
 MacOS
Message-ID: <1619599189.53.0.161750349555.issue43964@roundup.psfhosted.org>


New submission from Victor Lazzarini <Victor.Lazzarini at nuim.ie>:

With Python 3.9.4 ctypes.CDLL does not appear to find framework libraries installed in /Library/Frameworks.

--- With Python 3.6.5:

victor at MacBook-Pro ~ % python3                                         
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 03:03:55) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('CUDA.framework/CUDA')
<CDLL 'CUDA.framework/CUDA', handle 102b044b0 at 0x102c9b9e8>
>>> 

--- With Python 3.9.4

victor at MacBook-Pro ~ % python3.9
Python 3.9.4 (v3.9.4:1f2e3088f3, Apr  4 2021, 12:32:44) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('CUDA.framework/CUDA')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ctypes/__init__.py", line 374, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlopen(CUDA.framework/CUDA, 6): image not found
>>> 

This happens with all frameworks I have installed in /Library/Frameworks.
The full path seems to work OK:

>>> ctypes.CDLL('/Library/Frameworks/CUDA.framework/CUDA')
<CDLL '/Library/Frameworks/CUDA.framework/CUDA', handle 7fa358404180 at 0x7fa3580eeaf0>
>>> 

but that's suboptimal as in MacOS you might have frameworks installed elsewhere.

----------
components: macOS
messages: 392173
nosy: Victor.Lazzarini, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: ctypes CDLL search path issue on MacOS
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 28 05:34:28 2021
From: report at bugs.python.org (Sebastian Speitel)
Date: Wed, 28 Apr 2021 09:34:28 +0000
Subject: [New-bugs-announce] [issue43965] dataclasses.replace breaks when
 __init__ is overrriden in subclass
Message-ID: <1619602468.72.0.276909030716.issue43965@roundup.psfhosted.org>


New submission from Sebastian Speitel <sebastian.speitel at outlook.de>:

from dataclasses import dataclass, replace

@dataclass()
class A:
    a: int

class B(A):
    def __init__(self):
        super().__init__(a=1)

obj1 = B()
obj2 = replace(obj1, a=2)

  File "/usr/lib/python3.9/dataclasses.py", line 1284, in replace
    return obj.__class__(**changes)
TypeError: __init__() got an unexpected keyword argument 'a'


When a class extends a dataclass and overrides `__init__`, `replace` still accepts it as a dataclass according to the PEP but fails at constructing, since the `__init__`-signature doesn't match anymore.

----------
components: Library (Lib)
messages: 392174
nosy: SebastianSpeitel
priority: normal
severity: normal
status: open
title: dataclasses.replace breaks when __init__ is overrriden in subclass
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 28 08:44:15 2021
From: report at bugs.python.org (GPH)
Date: Wed, 28 Apr 2021 12:44:15 +0000
Subject: [New-bugs-announce] [issue43966] F String bugs with numpy.float32
Message-ID: <1619613855.19.0.40133405442.issue43966@roundup.psfhosted.org>


New submission from GPH <gphsmail at 163.com>:

When using F String with numpy.float32 variable, the output is wrong!

Example code:

```python
import numpy as np

floatNumber = 0.00123
print(f"num:{floatNumber}")

npFloatNumber = np.float32(0.00123)
print(f"num:{npFloatNumber}")
```

The output is:

```
num:0.00123
num:0.001230000052601099
```

As we can see, the value of np.float32 is wrong!

----------
messages: 392192
nosy: PingHGao
priority: normal
severity: normal
status: open
title: F String bugs with numpy.float32
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Apr 28 09:53:21 2021
From: report at bugs.python.org (Simon Aldrich)
Date: Wed, 28 Apr 2021 13:53:21 +0000
Subject: [New-bugs-announce] [issue43967] Valgrind memcheck on Py_Initialize
Message-ID: <1619618001.66.0.42182617734.issue43967@roundup.psfhosted.org>


New submission from Simon Aldrich <simon at aldrich.cc>:

Running a Valgrind memcheck of Py_Initialize still produces issues even when using the suggested suppressions file. Am I doing something wrong or is this expected?

I've attached a simple reproducer which can be run as follows:

1. Extract tarball
2. cmake
3. make memcheck (runs valgrind with suppressions)

Gives output similar to:

[100%] Built target valgrind-libpython
==2901== Memcheck, a memory error detector
==2901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2901== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2901== Command: ./valgrind-libpython
==2901== 
==2901== Conditional jump or move depends on uninitialised value(s)
==2901==    at 0x5729DB7: __wcsnlen_avx2 (strlen-avx2.S:264)
==2901==    by 0x5657CA1: wcsrtombs (wcsrtombs.c:104)
==2901==    by 0x55DDC40: wcstombs (wcstombs.c:34)
==2901==    by 0x4FB7EB9: _Py_EncodeLocaleRaw (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FB99F7: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FBB8B2: _PyPathConfig_Calculate (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FDAC8D: _PyConfig_InitPathConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE4F6E: PyConfig_Read (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE687A: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE79A1: Py_InitializeFromConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE7A5B: Py_InitializeEx (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x108758: main (in /home/simon/temp/valgrind-libpython/build/valgrind-libpython)
==2901== 
==2901== Conditional jump or move depends on uninitialised value(s)
==2901==    at 0x55C14E8: internal_utf8_loop (loop.c:298)
==2901==    by 0x55C14E8: __gconv_transform_internal_utf8 (skeleton.c:609)
==2901==    by 0x5657CD4: wcsrtombs (wcsrtombs.c:110)
==2901==    by 0x55DDC40: wcstombs (wcstombs.c:34)
==2901==    by 0x4FB7EB9: _Py_EncodeLocaleRaw (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FB99F7: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FBB8B2: _PyPathConfig_Calculate (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FDAC8D: _PyConfig_InitPathConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE4F6E: PyConfig_Read (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE687A: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE79A1: Py_InitializeFromConfig (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x4FE7A5B: Py_InitializeEx (in /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
==2901==    by 0x108758: main (in /home/simon/temp/valgrind-libpython/build/valgrind-libpython)...

----------
components: C API, Library (Lib)
files: valgrind-libpython.tar.gz
messages: 392199
nosy: simonaldrich
priority: normal
severity: normal
status: open
title: Valgrind memcheck on Py_Initialize
type: security
versions: Python 3.8
Added file: https://bugs.python.org/file49996/valgrind-libpython.tar.gz

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

From report at bugs.python.org  Wed Apr 28 12:26:16 2021
From: report at bugs.python.org (sfmc)
Date: Wed, 28 Apr 2021 16:26:16 +0000
Subject: [New-bugs-announce] [issue43968] os.path.realpath() unexpected
 breaking change: resolves subst'd paths to real paths
Message-ID: <1619627176.09.0.686852454721.issue43968@roundup.psfhosted.org>


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

For example if I mount directory
  C:\example\dir
to
  Z:\
the
  os.path.realpath('Z:\\')
returns the real directory.

Use following commands in Windows to reproduce the issue:

  md C:\example\dir
  subst Z: C:\example\dir
  python.exe -c "import os; print(os.path.realpath('Z:\\'))"

Python 3.8 outputs:
  C:\example\dir
Python 3.7 outputs:
  Z:\

This is unexpected behavior change and it breaks our scripts in many places, because we use mounts in Windows ("subst" command) and Linux ("mount" command).

We had to add our own implementation for realpath to our scripts, but it also affects other tools, such as Python debugger (breakpoints stopped working) and IDEs (such as PyCharm).

It can be argued whether the behavior to resolve mounts is good.

But this change breaks the ability to work with Python scripts in mounts.
I hope it can be fixed in Python 3.8.10.


I propose to fix it in Python 3.8.10 by adding to function
    os.path.realpath(path)
a new parameter (named for example "resolve_mounts"), like that:
    os.path.realpath(path, *, resolve_mounts=False)

And if resolve_mounts==False, then the function should not resolve mounts in Windows ("subst" command) and Linux ("mount" command).


Let me know if you wish to get a Pull Request with the proposed fix. I can try to implement it.

----------
components: Library (Lib)
messages: 392234
nosy: sfmc
priority: normal
severity: normal
status: open
title: os.path.realpath() unexpected breaking change: resolves subst'd paths to real paths
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Apr 28 16:36:52 2021
From: report at bugs.python.org (Mitchell Hentges)
Date: Wed, 28 Apr 2021 20:36:52 +0000
Subject: [New-bugs-announce] [issue43969] "bad magic number" when Python 2's
 pyc file exists without py file
Message-ID: <1619642212.93.0.461785778702.issue43969@roundup.psfhosted.org>


New submission from Mitchell Hentges <mitch9654 at gmail.com>:

Python 3 imports may fail if a Python 2 .pyc file exists without an accompanying .py file.

-----

My project vendors code, and we recently updated "requests" to a drastically newer version.

As part of this version change, `requests/packages/__init__.py` was removed, and  `requests/packages.py` was added.

This project is long-lived, and many people have imported `requests` with Python 2. So, `requests/packages/__init__.pyc` exists.

After making this update, importing requests with Python 3 fails:
`ImportError: bad magic number in 'parent.child': b'\x03\xf3\r\n'`

Interestingly, deleting `requests/packages/__init__.pyc` allows Python 3 to work again.

-----

I've attached a "reproduction" script that produces the directory structure and tweak required to cause the failure.
I'm running Python 2.7.18 and Python 3.9.1.

----------
components: Interpreter Core
files: repro.sh
messages: 392254
nosy: mitchhentges
priority: normal
severity: normal
status: open
title: "bad magic number" when Python 2's pyc file exists without py file
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49997/repro.sh

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

From report at bugs.python.org  Wed Apr 28 16:41:53 2021
From: report at bugs.python.org (Kevin Follstad)
Date: Wed, 28 Apr 2021 20:41:53 +0000
Subject: [New-bugs-announce] [issue43970] Optimize Path.cwd() in pathlib
Message-ID: <1619642513.35.0.170837369842.issue43970@roundup.psfhosted.org>


New submission from Kevin Follstad <kfollstad at gmail.com>:

python3.10 -m timeit -r 5 -n 100000 -s 'from pathlib import Path' 'Path.cwd()'
100000 loops, best of 5: 206 usec per loop

python3.10-mypatch -m timeit -r 5 -n 100000 -s 'from pathlib import Path' 'Path.cwd()'
100000 loops, best of 5: 156 usec per loop

----------
components: Library (Lib)
messages: 392255
nosy: kfollstad
priority: normal
severity: normal
status: open
title: Optimize Path.cwd() in pathlib
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Wed Apr 28 20:34:52 2021
From: report at bugs.python.org (Mohamed Moselhy)
Date: Thu, 29 Apr 2021 00:34:52 +0000
Subject: [New-bugs-announce] [issue43971] documentation: no spacing around
 default args in annotated function
Message-ID: <1619656492.65.0.621784631269.issue43971@roundup.psfhosted.org>


New submission from Mohamed Moselhy <look4d at gmail.com>:

See https://www.python.org/dev/peps/pep-0008/#function-annotations

The first section of https://docs.python.org/3/library/dataclasses.html shows quantity_on_hand: int=0, when there should be spacing around the '=' according to PEP 8 (see link above).

----------
assignee: docs at python
components: Documentation
files: screen.png
messages: 392271
nosy: docs at python, eric.araujo, ezio.melotti, mdk, moselhy, willingc
priority: normal
severity: normal
status: open
title: documentation: no spacing around default args in annotated function
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49998/screen.png

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

From report at bugs.python.org  Wed Apr 28 21:06:37 2021
From: report at bugs.python.org (Stephen Rosen)
Date: Thu, 29 Apr 2021 01:06:37 +0000
Subject: [New-bugs-announce] [issue43972] Simple HTTP Request Handler in
 http.server does not set a content-length and does not close connections on
 301s
Message-ID: <1619658397.03.0.0874955697236.issue43972@roundup.psfhosted.org>


New submission from Stephen Rosen <sirosen at globus.org>:

If you use the `http.server` simple server and handler to serve a directory, navigating to a directory name without a trailing slash will trigger a 301 to add the trailing slash.

For example, if "foo/" is a directory under the file server, a GET for "/foo" will receive a 301 Moved Permanently response with a Location header pointing at "/foo/".

However, the response is sent without a "Content-Length: 0" and the connection is not closed. Unfortunately, certain clients will hang indefinitely and wait under these conditions, without processing the redirect. In my testing, curl 7.68 and Firefox 87 both exhibted this behavior.

If a Content-Length header is set, these clients behave correctly.
For example, subclass the handler and add

    def send_response(self, code):
        super().send_response(code)
        if code == HTTPStatus.MOVED_PERMANENTLY:
            self.send_header("Content-Length", "0")

----------
components: Library (Lib)
messages: 392272
nosy: sirosen
priority: normal
severity: normal
status: open
title: Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 29 04:27:05 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 29 Apr 2021 08:27:05 +0000
Subject: [New-bugs-announce] [issue43973] Use Py_TPFLAGS_IMMUTABLETYPE in
 __class__ assignments check
Message-ID: <1619684825.72.0.216977603094.issue43973@roundup.psfhosted.org>


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

Use Py_TPFLAGS_IMMUTABLETYPE?iso. Py_TPFLAGS_HEAPTYPE in object_set_class().

See also:
- bpo-43908 (particularly msg392286)
- bpo-24912
- https://github.com/python/cpython/blob/e047239eafefe8b19725efffe7756443495cf78b/Objects/typeobject.c#L4620-L4668

----------
messages: 392290
nosy: erlendaasland, gvanrossum, pitrou, vstinner
priority: normal
severity: normal
status: open
title: Use Py_TPFLAGS_IMMUTABLETYPE in __class__ assignments check

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

From report at bugs.python.org  Thu Apr 29 05:02:26 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 29 Apr 2021 09:02:26 +0000
Subject: [New-bugs-announce] [issue43974] setup.py should set
 Py_BUILD_CORE_MODULE as defined macro
Message-ID: <1619686946.42.0.670507836309.issue43974@roundup.psfhosted.org>


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

CPython's setup.py contains lots of

  extra_compile_args = ['-DPy_BUILD_CORE_MODULE']

to mark modules as core module. Extra compiler args is the wrong option. It's also tedious and err-prone to define the macro in each and every Extension() class instance.

The compiler flag should be set automatically for all core extensions and it should use be set using the correct option define_macros.

----------
assignee: christian.heimes
components: Build
messages: 392293
nosy: christian.heimes, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: setup.py should set Py_BUILD_CORE_MODULE as defined macro
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Apr 29 05:15:48 2021
From: report at bugs.python.org (Scott Means)
Date: Thu, 29 Apr 2021 09:15:48 +0000
Subject: [New-bugs-announce] [issue43975] Incorrect MIME type returned for
 .js files Windows 10.
Message-ID: <1619687748.29.0.910634957661.issue43975@roundup.psfhosted.org>


New submission from Scott Means <smeans at gmail.com>:

This isn't *technically* a bug in Python, but it really presents like one. I like to run the http.server for quick-and-dirty web development, but today Chrome refused to load any of my .js files because the server is returning a MIME type of 'text/plain'. I downloaded server.py and played with it for a while, and realized that mimetypes.guess_type() is returning 'text/plain' for .js files. So then I read further into the code and realized that mimetypes is harvesting MIME types from the Windows registry. And for some reason, at least on my machine, HKEY_CLASSES_ROOT\.js\Content Type was 'text/plain'. Changing it to 'application/javascript' fixed my issue, but I'm guessing that a lot of Python devs won't bother to dig this deep. I don't know what an appropriate fix would be, other than to probably trust the built-in MIME types over the ones harvested from Windows.

----------
components: Library (Lib)
messages: 392294
nosy: smeans
priority: normal
severity: normal
status: open
title: Incorrect MIME type returned for .js files Windows 10.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 29 12:19:02 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Thu, 29 Apr 2021 16:19:02 +0000
Subject: [New-bugs-announce] [issue43976] Introduce mechanism to allow
 Python distributors to add custom site install schemes
Message-ID: <1619713142.43.0.43081473036.issue43976@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

As part of the distutils migration we plan to add a mechanism to let Python distributors to add site install schemes.

Currently, Python distributors are patching distutils to add custom install schemes for their packages. I think most of the reasoning boils down to them wanting to stop Python installers, such as pip, to modify/interfere with their packages.

With the distutils deprecation, and it becoming a 3rd party module, Python distributors can no longer patch it. Because of this, we made distutils use the sysconfig module instead, which fixes the issue at the moment -- Python distributors can now patch sysconfig itself -- but is not a long term solution.
To prevent Python distributors from having to patch implementation details, and have things break unexpectedly, we aim to introduce a system that distributors can use for this purpose.

The idea is that they have a config file, which they can pass to configure, and in that config file they can specify some extra install schemes. These install schemes will get added in sysconfig, and will be loaded in the site module initialization.

In practice, it will look something like this:

config.py
```
EXTRA_SITE_INSTALL_SCHEMES = {
    'posix_prefix': {
        'stdlib': '{installed_base}/{platlibdir}/python{py_version_short}',
        'platstdlib': '{platbase}/{platlibdir}/python{py_version_short}',
        'purelib': '{base}/lib/python{py_version_short}/vendor-packages',
        'platlib': '{platbase}/{platlibdir}/python{py_version_short}/vendor-packages',
        'include':
            '{installed_base}/include/python{py_version_short}{abiflags}',
        'platinclude':
            '{installed_platbase}/include/python{py_version_short}{abiflags}',
        'scripts': '{base}/bin',
        'data': '{base}',
    },
}
```

./configure --with-vendor-config=config.py

----------
components: Library (Lib)
messages: 392326
nosy: FFY00, jaraco
priority: normal
pull_requests: 24414
severity: normal
status: open
title: Introduce mechanism to allow Python distributors to add custom site install schemes
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 29 12:33:41 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 29 Apr 2021 16:33:41 +0000
Subject: [New-bugs-announce] [issue43977] Implement the latest semantics for
 PEP 634 for matching collections
Message-ID: <1619714021.85.0.37223153861.issue43977@roundup.psfhosted.org>


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

PEP 634 has been updated to allow a faster and more robust implementation of matching sequences and mappings: https://github.com/python/peps/pull/1937

It needs to be implemented.

----------
assignee: Mark.Shannon
messages: 392330
nosy: Mark.Shannon
priority: high
severity: normal
status: open
title: Implement the latest semantics for PEP 634 for matching collections

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

From report at bugs.python.org  Thu Apr 29 14:16:06 2021
From: report at bugs.python.org (Mariatta)
Date: Thu, 29 Apr 2021 18:16:06 +0000
Subject: [New-bugs-announce] [issue43978] Incorrect "versionadded" info in
 typing.NoReturn documentation
Message-ID: <1619720166.99.0.648507362303.issue43978@roundup.psfhosted.org>


New submission from Mariatta <mariatta at python.org>:

We received a documentation bug report in docs mailing list.

https://mail.python.org/archives/list/docs at python.org/thread/BLANNZUPUEOJ4LJYSJNNFLK5I7NYE3GH/#

It looks like the doc currently says that, typing.NoReturn was added in both 3.5.4 and 3.6.2

It appeared from this change, that it was originally added in 3.6.5 (https://github.com/python/cpython/pull/7107/files)

However, during a refactoring effort, in https://github.com/python/cpython/commit/ab72fdeb82c3ab045b480cd4bb4f928c12653ecb, the 3.5.4 and 3.6.2 info were added, perhaps due to copy-pasting.

I think it should be changed into .. versionadded:: 3.6.5

However, I'm curious to know whether there are other parts in the doc, where this info is wrong. So perhaps there was other parts of the doc that was added in 3.5.4, but somehow we moved that to the typing.NoReturn section.

For now, I think we can just fix it by adding .. versionadded: 3.6.5

And maybe someone else can look into other parts of the doc to see if the version info are correct.

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 392341
nosy: Mariatta, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Incorrect "versionadded" info in typing.NoReturn documentation
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 29 15:29:25 2021
From: report at bugs.python.org (Christoph Zwerschke)
Date: Thu, 29 Apr 2021 19:29:25 +0000
Subject: [New-bugs-announce] [issue43979] Simplify urllib.parse_qsl
Message-ID: <1619724565.9.0.228522372223.issue43979@roundup.psfhosted.org>


New submission from Christoph Zwerschke <cito at online.de>:

Just noticed the following code in urrlib.parse_qsl:

    pairs = [s1 for s1 in qs.split(separator)]
    for name_value in pairs:
        ...

see https://github.com/python/cpython/blob/088a15c49d99ecb4c3bef93f8f40dd513c6cae3b/Lib/urllib/parse.py#L755

This looks like an unnecessary list comprehension to me, probably a relic of earlier code that used a nested list comprehension for splitting with two different separators.

Can't we just do this instead now, which is faster and shorter?

   for name_value qs.split(separator):

I can provide a PR if wanted.

----------
components: Library (Lib)
messages: 392345
nosy: cito
priority: normal
severity: normal
status: open
title: Simplify urllib.parse_qsl
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/issue43979>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:02:55 2021
From: report at bugs.python.org (Jerry Heiselman)
Date: Thu, 29 Apr 2021 20:02:55 +0000
Subject: [New-bugs-announce] [issue43980] netrc module looks for .netrc even
 on Windows where the convention is _netrc
Message-ID: <1619726575.32.0.12245776965.issue43980@roundup.psfhosted.org>


New submission from Jerry Heiselman <jerry at heiselman.com>:

The netrc library defaults to looking for the .netrc file in the user's home directory. On Windows, this file is conventionally named _netrc. While one could pass the correct path to the library, the conventionally correct path should be used on all supported platforms.

----------
components: Library (Lib)
messages: 392348
nosy: jheiselman
priority: normal
severity: normal
status: open
title: netrc module looks for .netrc even on Windows where the convention is _netrc
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/issue43980>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:29:20 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 29 Apr 2021 21:29:20 +0000
Subject: [New-bugs-announce] [issue43981] test_idle is leaking references
Message-ID: <1619731760.39.0.648399014878.issue43981@roundup.psfhosted.org>


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

See for example:

https://buildbot.python.org/all/#/builders/511/builds/10/steps/4/logs/stdio

test_idle leaked [684, 684, 684] references, sum=2052
test_idle leaked [282, 282, 282] memory blocks, sum=846

----------
assignee: terry.reedy
components: IDLE
messages: 392353
nosy: pablogsal, terry.reedy
priority: release blocker
severity: normal
status: open
title: test_idle is leaking references

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

From report at bugs.python.org  Thu Apr 29 19:36:48 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2021 23:36:48 +0000
Subject: [New-bugs-announce] [issue43982] Code coverage on the CI: validate
 codecov shell script checksum
Message-ID: <1619739408.19.0.291224882585.issue43982@roundup.psfhosted.org>


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

Currently, GitHub Action and Travis CI run a codecov bash downloaded from https://codecov.io/bash without validating it.

The script was recently compromised:
https://about.codecov.io/security-update/

We should validate the shell script integrity by checking its checksum. Example from the documentation:
-------------
curl -s https://codecov.io/bash > codecov;
VERSION=$(grep -o 'VERSION=\"[0-9\.]*\"' codecov | cut -d'"' -f2);
for i in 1 256 512
do
  shasum -a $i -c --ignore-missing <(curl -s "https://raw.githubusercontent.com/codecov/codecov-bash/${VERSION}/SHA${i}SUM") ||
  shasum -a $i -c <(curl -s "https://raw.githubusercontent.com/codecov/codecov-bash/${VERSION}/SHA${i}SUM")
done
-------------

See: https://docs.codecov.io/docs/about-the-codecov-bash-uploader

----------
components: Tests
messages: 392362
nosy: vstinner
priority: normal
severity: normal
status: open
title: Code coverage on the CI: validate codecov shell script checksum
versions: Python 3.10

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

From report at bugs.python.org  Thu Apr 29 23:56:37 2021
From: report at bugs.python.org (Marwan Essam)
Date: Fri, 30 Apr 2021 03:56:37 +0000
Subject: [New-bugs-announce] [issue43983] Can't install Python v3.9.4 /
 0x80070643 / windows 10 64bit
Message-ID: <1619754997.92.0.813433762257.issue43983@roundup.psfhosted.org>


New submission from Marwan Essam <marwanes1818 at gmail.com>:

Hello, 
While I was trying to install Python version 3.9.4 on Windows 10 64bit, Error 0x80070643 - Fatal error during installation is showing, with a message saying " install the process cannot access the file because another process has locked a portion of the file", 

Note: There was an older version of Python installed on my laptop in 2018, but a while ago i did a system format, but some of the .XMl and .py files still there ( i don't know if that's the case)

Core_AllUsers (https://pastebin.com/iAZGTrkx)

----------
components: Installation
files: Python 3.9.4 (64-bit)_20210430053233.log
messages: 392378
nosy: Marwan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't install Python v3.9.4 / 0x80070643 / windows 10 64bit
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50000/Python 3.9.4 (64-bit)_20210430053233.log

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

From report at bugs.python.org  Fri Apr 30 04:42:01 2021
From: report at bugs.python.org (r3pwnx)
Date: Fri, 30 Apr 2021 08:42:01 +0000
Subject: [New-bugs-announce] [issue43984] [security]winreg.SetValueEx shoule
 check the returned value
Message-ID: <1619772121.59.0.631498595724.issue43984@roundup.psfhosted.org>


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

The library winreg[1] can be used to access registry on windows.  
>reg.SetValueEx(key, 'X', 0, reg.REG_DWORD, -1337)  
`SetValueEx` could store data in the value field of an open registry key, 

In the source file of "PC/winreg.c", `Py2Reg`is called first

```
static PyObject *
winreg_SetValueEx_impl(PyObject *module, HKEY key,
                       const Py_UNICODE *value_name, PyObject *reserved,
                       DWORD type, PyObject *value)
/*[clinic end generated code: output=811b769a66ae11b7 input=900a9e3990bfb196]*/
{
    BYTE *data;
    DWORD len;

    LONG rc;

    if (!Py2Reg(value, type, &data, &len))
    ...
```

`Py2Reg` is implemented in the same file:

```
Py2Reg(PyObject *value, DWORD typ, BYTE **retDataBuf, DWORD *retDataSize)
{
    Py_ssize_t i,j;
    switch (typ) {
        case REG_DWORD:
            if (value != Py_None && !PyLong_Check(value))
                return FALSE;
            *retDataBuf = (BYTE *)PyMem_NEW(DWORD, 1);
            if (*retDataBuf == NULL){
                PyErr_NoMemory();
                return FALSE;
            }
            *retDataSize = sizeof(DWORD);
            if (value == Py_None) {
                DWORD zero = 0;
                memcpy(*retDataBuf, &zero, sizeof(DWORD));
            }
            else {
                DWORD d = PyLong_AsUnsignedLong(value);
                memcpy(*retDataBuf, &d, sizeof(DWORD));
            }
            break;
```

When the type is set with reg.REG_DWORD, `PyLong_AsUnsignedLong(value)` will change  the value's type, and then memcpy the returned value directly, without any check.  

In the Objects/longobject.c, as the comment said:

/* Get a C unsigned long int from an int object.
   Returns -1 and sets an error condition if overflow occurs. */

If PyLong_AsUnsignedLong return -1, the -1 will be stored in the registry though the error occured


PoC:


import winreg as reg

key = reg.CreateKey(reg.HKEY_CURRENT_USER, 'SOFTWARE\\Classes\\r3pwn')

try:
	print("Set Subkey X: -1337")
	reg.SetValueEx(key, 'X', 0, reg.REG_DWORD, -1337)
except Exception as e:
	print("Get Subkey: ", reg.QueryValueEx(key, "X")[0])

try:
	print("Set Subkey Y: 2**33")
	reg.SetValueEx(key, 'Y', 0, reg.REG_DWORD, 2**33)
except Exception as e:
	print("Get Subkey: ", reg.QueryValueEx(key, "Y")[0])

The Test Environment
OS: Windows
Python Version: 3.9.0

python winreg_bug.py
Set Subkey X: -1337
Get Subkey:  4294967295
Set Subkey Y: 2**33
Get Subkey:  4294967295

the return value should be checked:

     DWORD d = PyLong_AsUnsignedLong(value);
 +   if (d == (unsigned long)-1 && PyErr_Occurred())
 +       return False;
     memcpy(*retDataBuf, &d, sizeof(DWORD));


[1] https://docs.python.org/3.9/library/winreg.html#winreg.SetValueEx

----------
components: Library (Lib)
files: winreg_bug.py
messages: 392392
nosy: r3pwnx
priority: normal
severity: normal
status: open
title: [security]winreg.SetValueEx shoule check the returned value
type: security
versions: Python 3.9
Added file: https://bugs.python.org/file50001/winreg_bug.py

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

From report at bugs.python.org  Fri Apr 30 05:13:19 2021
From: report at bugs.python.org (MisterY)
Date: Fri, 30 Apr 2021 09:13:19 +0000
Subject: [New-bugs-announce] [issue43985] lib2to3 fails on a slash('/')
 after positional_only paramter in a function signature
Message-ID: <1619773999.71.0.976302612152.issue43985@roundup.psfhosted.org>


New submission from MisterY <cloud2037 at gmail.com>:

When I try to format a code snippet with yapf, there comes a error.
It seems lib2to3 can't reconised SLASH.

echo "def foo(posonly1, posonly2, /, positional_or_keyword): pass" | yapf 

Traceback (most recent call last):
  File "d:\program files\python38\lib\site-packages\yapf\yapflib\pytree_utils.py", line 115, in ParseCodeToTree
    tree = parser_driver.parse_string(code, debug=False)
  File "d:\program files\python38\lib\lib2to3\pgen2\driver.py", line 103, in parse_string
    return self.parse_tokens(tokens, debug)
  File "d:\program files\python38\lib\lib2to3\pgen2\driver.py", line 71, in parse_tokens
    if p.addtoken(type, value, (prefix, start)):
  File "d:\program files\python38\lib\lib2to3\pgen2\parse.py", line 162, in addtoken
    raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=17, value='/', context=(' ', (1, 28))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "d:\program files\python38\lib\runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "d:\program files\python38\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "D:\Program Files\Python38\Scripts\yapf.exe\__main__.py", line 7, in <module>
  File "d:\program files\python38\lib\site-packages\yapf\__init__.py", line 362, in run_main
    sys.exit(main(sys.argv))
  File "d:\program files\python38\lib\site-packages\yapf\__init__.py", line 104, in main
    reformatted_source, _ = yapf_api.FormatCode(
  File "d:\program files\python38\lib\site-packages\yapf\yapflib\yapf_api.py", line 147, in FormatCode
    tree = pytree_utils.ParseCodeToTree(unformatted_source)
  File "d:\program files\python38\lib\site-packages\yapf\yapflib\pytree_utils.py", line 121, in ParseCodeToTree
    tree = parser_driver.parse_string(code, debug=False)
  File "d:\program files\python38\lib\lib2to3\pgen2\driver.py", line 103, in parse_string
    return self.parse_tokens(tokens, debug)
  File "d:\program files\python38\lib\lib2to3\pgen2\driver.py", line 71, in parse_tokens
    if p.addtoken(type, value, (prefix, start)):
  File "d:\program files\python38\lib\lib2to3\pgen2\parse.py", line 162, in addtoken
    raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=17, value='/', context=(' ', (1, 28))

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 392396
nosy: cloud-yu
priority: normal
severity: normal
status: open
title: lib2to3 fails on a slash('/') after positional_only paramter in a function signature
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 30 07:15:38 2021
From: report at bugs.python.org (Kat Hoessel)
Date: Fri, 30 Apr 2021 11:15:38 +0000
Subject: [New-bugs-announce] [issue43986] ipaddress: increment/decrement on
 IPv*Interface disregards bitmask prefix
Message-ID: <1619781338.67.0.912889230894.issue43986@roundup.psfhosted.org>


New submission from Kat Hoessel <kat.hoessel at uninett.no>:

IPv4 and IPv6 interface objects of the `ipaddress` library show unexpected behaviour when arithmetic operators like + (increment) and - (decrement) are run on them.


`ipaddress` interfaces can be incremented/decremented, similar to IP addresses.
Currently, there are two problems with how these operations are implemented for interfaces within this library.
This applies to both IPv4 and IPv6, and may yield incorrect and inconsistent results.


1. Increment/decrement on an interface overrides subnet prefix length

The resulting interface will always have a prefix length of /32 for IPv4, /128 for IPv6, regardless of the original interface prefix. (See iPython code examples below.)
This behaviour is incomprehensible and unexpected.


2. Increment/decrement on an interface does not respect subnet arithmetic

For example,

    ipaddress.ip_interface('10.0.0.1/24') + 255

has no valid result under subnet arithmetic.
`ipaddress` however, incorrectly returns

    IPv4Interface('10.0.1.0/32')


It is likely that the behaviour seen in 2) logically follows after 1).
Both are assumedly related to the fact that IPv*Interface is a subclass of IPv*Address with inherited properties.


To achieve consistent behaviour for interfaces under +/-, I would suggest to either

  a) make sure that +/- operators on interfaces preserve the prefix and respect subnet arithmetic, or
  b) forbid +/- operators on interfaces.

My preferred solution would be a). I would be interested in providing a patch, given that the observed behaviour is confirmed as a bug.


----------------------------------------------------------------
### IPv4

In [1]: import ipaddress

In [2]: iff = ipaddress.ip_interface('10.0.0.1/24')

In [3]: iff
Out[3]: IPv4Interface('10.0.0.1/24')

In [4]: iff1 = iff + 1

In [5]: iff1
Out[5]: IPv4Interface('10.0.0.2/32')

In [6]: iff.network.prefixlen
Out[6]: 24

In [7]: iff1.network.prefixlen
Out[7]: 32

### overflow

In [8]: iff + 255  # this should not work
Out[8]: IPv4Interface('10.0.1.0/32')

### IPv6

In [9]: iff = ipaddress.ip_interface('1:1:1:2::1/64')

In [10]: iff
Out[10]: IPv6Interface('1:1:1:2::1/64')

In [11]: iff + 1
Out[11]: IPv6Interface('1:1:1:2::2/128')

### version information

In [12]: import sys

In [13]: sys.version
Out[13]: '3.8.3 (default, Aug 31 2020, 16:03:14) \n[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]'

----------
components: Library (Lib)
messages: 392417
nosy: katsel
priority: normal
severity: normal
status: open
title: ipaddress: increment/decrement on IPv*Interface disregards bitmask prefix
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 30 07:26:13 2021
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 30 Apr 2021 11:26:13 +0000
Subject: [New-bugs-announce] [issue43987] Add "Annotations Best Practices"
 to HOWTO
Message-ID: <1619781973.9.0.643111119253.issue43987@roundup.psfhosted.org>


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

Dealing with annotations is complicated.  I think there should be a section of the Python documentation describing best practices for working
with annotations.  So, here goes.

The best spot I found for it was as a new HOWTO.  I added links to that HOWTO to a couple relevant glossary definitions, and one in the documentation for inspect.get_annotations().  I'm not sure if it makes sense to add any other links; I considered adding links to the HOWTO to where the __annotations__ attribute is defined on functions, modules, and classes, in reference/datamodel.rst, but it just didn't seem like a good idea.

----------
assignee: larry
components: Documentation
messages: 392419
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "Annotations Best Practices" to HOWTO
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 30 10:12:30 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 30 Apr 2021 14:12:30 +0000
Subject: [New-bugs-announce] [issue43988] Add
 test.support.assert_dissallow_instantiation
Message-ID: <1619791950.5.0.60645292756.issue43988@roundup.psfhosted.org>


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

See https://github.com/python/cpython/pull/25748#discussion_r623849521:
"What do you think of adding support.assert_disallow_instanciation(type, *args) function which would check for TypeError but also check the error message? TypeError is quite generic and it might hide a bug."


Ref. bpo-43916.

----------
components: Tests
messages: 392436
nosy: erlendaasland, vstinner
priority: normal
severity: normal
status: open
title: Add test.support.assert_dissallow_instantiation

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

From report at bugs.python.org  Fri Apr 30 13:16:16 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 30 Apr 2021 17:16:16 +0000
Subject: [New-bugs-announce] [issue43989] Enum deprecation breaks SSL tests
Message-ID: <1619802976.1.0.850329373801.issue43989@roundup.psfhosted.org>


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

Ethan,

a recent change to enum module breaks ssltests. I'm running ssltests with python -Werror to detect deprecation issues. Could you please look into the matter and address the deprecation warning in asyncio?

https://github.com/python/cpython/runs/2477299020

 ======================================================================
ERROR: test_add_signal_handler_install_error3 (test.test_asyncio.test_unix_events.SelectorEventLoopSignalTests)
----------------------------------------------------------------------
test test_asyncio failed
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/asyncio/unix_events.py", line 116, in add_signal_handler
    signal.signal(sig, _sighandler_noop)
  File "/home/runner/work/cpython/cpython/Lib/unittest/mock.py", line 1105, in __call__
    return self._mock_call(*args, **kwargs)
  File "/home/runner/work/cpython/cpython/Lib/unittest/mock.py", line 1109, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
  File "/home/runner/work/cpython/cpython/Lib/unittest/mock.py", line 1164, in _execute_mock_call
    raise effect
test.test_asyncio.test_unix_events.SelectorEventLoopSignalTests.test_add_signal_handler_install_error3.<locals>.Err

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/unittest/mock.py", line 1370, in patched
    return func(*newargs, **newkeywargs)
  File "/home/runner/work/cpython/cpython/Lib/test/test_asyncio/test_unix_events.py", line 165, in test_add_signal_handler_install_error3
    self.assertRaises(
  File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 732, in assertRaises
    return context.handle('assertRaises', args, kwargs)
  File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 201, in handle
    callable_obj(*args, **kwargs)
  File "/home/runner/work/cpython/cpython/Lib/asyncio/unix_events.py", line 129, in add_signal_handler
    raise RuntimeError(f'sig {sig} cannot be caught')
  File "/home/runner/work/cpython/cpython/Lib/enum.py", line 1019, 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 IntEnum member, to maintainthe current display

----------
assignee: ethan.furman
components: Library (Lib), Tests, asyncio
keywords: 3.10regression, 3.9regression
messages: 392478
nosy: asvetlov, barry, christian.heimes, eli.bendersky, ethan.furman, yselivanov
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Enum deprecation breaks SSL tests
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Apr 30 13:33:30 2021
From: report at bugs.python.org (Webb Scales)
Date: Fri, 30 Apr 2021 17:33:30 +0000
Subject: [New-bugs-announce] [issue43990] In documentation Section 6.17,
 Operator precedence, footnotes 5 & 6 are reversed
Message-ID: <1619804010.67.0.84044375696.issue43990@roundup.psfhosted.org>


New submission from Webb Scales <wscales at redhat.com>:

In Section 6.17 ("Operator precedence"; https://docs.python.org/3/reference/expressions.html#operator-precedence) of the documentation, footnote 5 (https://docs.python.org/3/reference/expressions.html#id15) refers to text (https://docs.python.org/3/reference/expressions.html#id21) which applies to reference 6, while footnote 6 refers to text which applies to reference 5.

----------
assignee: docs at python
components: Documentation
messages: 392481
nosy: docs at python, webbnh
priority: normal
severity: normal
status: open
title: In documentation Section 6.17, Operator precedence, footnotes 5 & 6 are reversed
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 30 14:49:44 2021
From: report at bugs.python.org (=?utf-8?q?Alexander_Niederb=C3=BChl?=)
Date: Fri, 30 Apr 2021 18:49:44 +0000
Subject: [New-bugs-announce] [issue43991] asyncio lock does not get released
 after task is canceled
Message-ID: <1619808584.15.0.419311675075.issue43991@roundup.psfhosted.org>


New submission from Alexander Niederb?hl <a.niederbuehl at gmail.com>:

If a task gets canceled while holding a lock, the lock is not automatically released. Is that expected, it seems like it could cause a deadlock?

Failing test adapted from Lib/test/test_asyncio/test_locks.py (commit 6bd9288b80):

    def test_acquire_cancel(self):
        lock = asyncio.Lock()
        self.assertTrue(self.loop.run_until_complete(lock.acquire()))

        task = self.loop.create_task(lock.acquire())
        self.loop.call_soon(task.cancel)
        self.assertRaises(
            asyncio.CancelledError,
            self.loop.run_until_complete, task)
        self.assertFalse(lock._waiters)

        # Should the lock get released after cancellation?
        self.assertFalse(lock.locked())

I stumbled upon this while playing around with TLA+.

----------
components: asyncio
messages: 392499
nosy: a.niederbuehl, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio lock does not get released after task is canceled
type: behavior

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

From report at bugs.python.org  Fri Apr 30 14:53:40 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Fri, 30 Apr 2021 18:53:40 +0000
Subject: [New-bugs-announce] [issue43992] Unable to get external
 dependencies for CPython on Ubuntu Linux 20.04.1
Message-ID: <1619808820.38.0.0813817869206.issue43992@roundup.psfhosted.org>


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

I'm trying to build CPython on Ubuntu but I can't get the external dependencies. Running this command :-

$ sudo apt-get build-dep python3

gives the output :-

Reading package lists... Done
E: You must put some 'deb-src' URIs in your sources.list

What is the exact string to add to /etc/apt/sources.list?

System Info: Ubuntu 20.04.1 (Focal Fossa)
Architecture: x64
GCC version: 9.3.0

(I've posted the problem in this issue tracker because Google and Stack Overflow doesn't seem to have an answer. I'm sorry for posting this here but no one seem to have the answer to this apart from core or experienced developers.)

----------
messages: 392500
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Unable to get external dependencies for CPython on Ubuntu Linux 20.04.1

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

From report at bugs.python.org  Fri Apr 30 14:55:41 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Bidoul?=)
Date: Fri, 30 Apr 2021 18:55:41 +0000
Subject: [New-bugs-announce] [issue43993] Upda
Message-ID: <1619808941.36.0.183974538223.issue43993@roundup.psfhosted.org>


Change by St?phane Bidoul <stephane.bidoul at acsone.eu>:


----------
nosy: sbidoul
priority: normal
severity: normal
status: open
title: Upda

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

From report at bugs.python.org  Fri Apr 30 18:49:51 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 30 Apr 2021 22:49:51 +0000
Subject: [New-bugs-announce] [issue43994] change representation of match as
 / capture as `Name(..., ctx=Store())`
Message-ID: <1619822991.2.0.658600538684.issue43994@roundup.psfhosted.org>


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

I'm looking at adding support to `match` for pyflakes, and the first impression I have is that `MatchAs` is unnecessarily different from `Name` with `ctx=Store()`

if it were represented as the latter pyflakes would not require special handling of `match`, it would work the same as the current code

I suspect other static analysis tools would benefit from a change as well

----------
messages: 392531
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: change representation of match as / capture as `Name(..., ctx=Store())`
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 30 18:56:43 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 30 Apr 2021 22:56:43 +0000
Subject: [New-bugs-announce] [issue43995] test_grammar fails if run
 sequentially
Message-ID: <1619823403.82.0.693655826383.issue43995@roundup.psfhosted.org>


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

To reproduce:
$ ./python.exe -m test test_typing test_grammar
0:00:00 load avg: 1.95 Run tests sequentially
0:00:00 load avg: 1.95 [1/2] test_typing
0:00:00 load avg: 1.95 [2/2] test_grammar
test test_grammar failed -- Traceback (most recent call last):
  File "/Users/erlendaasland/src/cpython-support/Lib/test/test_grammar.py", line 396, in test_var_annot_in_module
    with self.assertRaises(NameError):
AssertionError: NameError not raised

test_grammar failed

== Tests result: FAILURE ==

1 test OK.

1 test failed:
    test_grammar

Total duration: 969 ms
Tests result: FAILURE

----------
components: Tests
messages: 392532
nosy: erlendaasland, pablogsal
priority: normal
severity: normal
status: open
title: test_grammar fails if run sequentially
versions: Python 3.10

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

From report at bugs.python.org  Fri Apr 30 20:34:44 2021
From: report at bugs.python.org (Mark Sapiro)
Date: Sat, 01 May 2021 00:34:44 +0000
Subject: [New-bugs-announce] [issue43996] Doc for mutable sequence pop()
 method implies argument is a slice or sequence.
Message-ID: <1619829284.94.0.13979953876.issue43996@roundup.psfhosted.org>


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

In several places in the documentation including:

```
grep -rn 'pop.\[i\]'
Lib/pydoc_data/topics.py:13184:             '| "s.pop([i])"                   | retrieves the item at *i* '
Lib/pydoc_data/topics.py:13647:                     '| "s.pop([i])"                   | retrieves the item at '
Doc/tutorial/datastructures.rst:47:.. method:: list.pop([i])
Doc/library/array.rst:193:.. method:: array.pop([i])
Doc/library/stdtypes.rst:1116:| ``s.pop([i])``               | retrieves the item at *i* and  | \(2)                |
```
the mutable sequence and array `pop()` method is documented as shown above in a way that implies the argument to `pop()` is a slice or sequence when it is actually just an integer. All those references should be `pop(i)` rather than `pop([i])`.

----------
assignee: docs at python
components: Documentation
messages: 392551
nosy: docs at python, msapiro
priority: normal
severity: normal
status: open
title: Doc for mutable sequence pop() method implies argument is a slice or sequence.
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/issue43996>
_______________________________________

From report at bugs.python.org  Fri Apr 30 22:12:42 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 01 May 2021 02:12:42 +0000
Subject: [New-bugs-announce] [issue43997] dataclasses documentation needs
 version added for match_args, kw_only, and slots
Message-ID: <1619835162.18.0.39388783507.issue43997@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: dataclasses documentation needs version added for match_args, kw_only, and slots
versions: Python 3.10

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