From report at bugs.python.org  Thu Oct  1 04:09:31 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 01 Oct 2020 08:09:31 +0000
Subject: [New-bugs-announce] [issue41900] XML C14N serialisation fails with
 default namespace
Message-ID: <1601539771.76.0.649263421271.issue41900@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

import xml.etree.ElementTree as ET
xml="""
<X xmlns="http://soap.sforce.com/2006/04/metadata">
    <Y targets="lightning__AppPage,lightning__HomePage"></Y>
</X>"""
print(ET.canonicalize(xml))

Fails with:
ValueError: Namespace "" is not declared in scope
when trying to build the QName of the unnamespaced "targets" attribute.

Originally reported for lxml here:
https://bugs.launchpad.net/lxml/+bug/1869455

----------
components: XML
messages: 377743
nosy: scoder
priority: normal
severity: normal
stage: needs patch
status: open
title: XML C14N serialisation fails with default namespace
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct  1 08:07:50 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 01 Oct 2020 12:07:50 +0000
Subject: [New-bugs-announce] [issue41901] Added some explaining to pickle
 errors.
Message-ID: <1601554070.38.0.74604376475.issue41901@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

All pickle error messages in typeobject.c was a generic "cannot pickle 'type' object". Added some explaining for every individual error.

----------
components: Interpreter Core
messages: 377747
nosy: Marco Sulla
priority: normal
pull_requests: 21494
severity: normal
status: open
title: Added some explaining to pickle errors.
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  1 09:42:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 01 Oct 2020 13:42:45 +0000
Subject: [New-bugs-announce] [issue41902] Micro optimization for range.index
 if step is 1
Message-ID: <1601559765.96.0.883895901539.issue41902@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

if we declare range without setting step, we don't have to process divide operation.

here is the benchmark result both setting step and without step,

With my patch, there is no performance degrade with range.index when the step is not one and showing 19% enhancement when the step is the default value (1) .

Mean +- std dev: [range_master] 1.11 us +- 0.01 us -> [range_opt] 896 ns +- 23 ns: 1.24x faster (-19%)

Mean +- std dev: [range_step_master] 1.12 us +- 0.02 us -> [range_step_opt] 1.11 us +- 0.01 us: 1.01x faster (-1%)

----------
assignee: corona10
components: Interpreter Core
files: bench_range_index.py
messages: 377752
nosy: corona10, pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Micro optimization for range.index if step is 1
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49482/bench_range_index.py

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

From report at bugs.python.org  Thu Oct  1 11:10:02 2020
From: report at bugs.python.org (Simon Cross)
Date: Thu, 01 Oct 2020 15:10:02 +0000
Subject: [New-bugs-announce] [issue41903] PyNumber_InPlacePower ignores o3
 if o1 implements __ipow__
Message-ID: <1601565002.5.0.364385542307.issue41903@roundup.psfhosted.org>


New submission from Simon Cross <hodgestar at gmail.com>:

The documentation for PyNumber_InPlacePower [1] reads:

This is the equivalent of the Python statement o1 **= o2 when o3 is Py_None, or an in-place variant of pow(o1, o2, o3) otherwise. If o3 is to be ignored, pass Py_None in its place (passing NULL for o3 would cause an illegal memory access).

However, if a class A implements __ipow__ then PyNumber_InPlacePower(o1, o2, o3) ALWAYS ignores o3 if o1 is an instance of A.

This happens because if A implements __ipow__ then PyNumber_InPlacePower always calls the nb_inplace_power slot [2] and the slot always drops the third argument [3].

This appears to have always been the case in Python, so likely a small documentation patch is all that is required. If people agree, I will open a documentation pull request.

[1] https://docs.python.org/3/c-api/number.html?highlight=pynumber_inplacepower#c.PyNumber_InPlacePower

[2] https://github.com/python/cpython/blob/master/Objects/abstract.c#L1164

[3] https://github.com/python/cpython/blob/master/Objects/typeobject.c#L6631-L6636

----------
components: C API
messages: 377758
nosy: hodgestar
priority: normal
severity: normal
status: open
title: PyNumber_InPlacePower ignores o3 if o1 implements __ipow__
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct  1 11:54:18 2020
From: report at bugs.python.org (Damian Yurzola)
Date: Thu, 01 Oct 2020 15:54:18 +0000
Subject: [New-bugs-announce] [issue41904] datetime.datetime.today makes no
 sense and should be removed
Message-ID: <1601567658.27.0.420109981563.issue41904@roundup.psfhosted.org>


New submission from Damian Yurzola <damian at yurzola.net>:

Last night I discovered we have datetime.datetime.today alongside
datetime.datetime.now and datetime.date.today.

- datetime.now
- date.today

Both make semantic sense.

datetime.datetime.today returns a datetime, which make no semantic sense and causes confusion.

On further inspection of the code, this is due to the fact that datetime inherits from date.

so datetime.today is practically an implementation of datetime.now minus the "tz".

I think we should implement a datetime.today only to rise an AttributeError or some other way to stop people from using the wrong semantic mental model.
We'd also need to remove the documentation entry: 
https://docs.python.org/3/library/datetime.html#datetime.datetime.today


>From this inspection we also find that:

datetime.hour/minute/second are unnecessarily redefined.
lines Lib/datetime.py#L1606 to datetime.py#L1620

could be removed without any ill effect.






date.today:
https://github.com/python/cpython/blob/256e54acdbdb26745d4bbb5cf366454151e42773/Lib/datetime.py#L833



https://docs.python.org/3/library/datetime.html#datetime.datetime.today

----------
components: Library (Lib)
messages: 377768
nosy: yurzo
priority: normal
severity: normal
status: open
title: datetime.datetime.today makes no sense and should be removed

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

From report at bugs.python.org  Thu Oct  1 11:54:52 2020
From: report at bugs.python.org (Ben Avrahami)
Date: Thu, 01 Oct 2020 15:54:52 +0000
Subject: [New-bugs-announce] [issue41905] add update_abstractmethods
 function to update an ABC's abstract methods
Message-ID: <1601567692.16.0.144251091539.issue41905@roundup.psfhosted.org>


New submission from Ben Avrahami <avrahami.ben at gmail.com>:

python-ideas discussion:
https://mail.python.org/archives/list/python-ideas at python.org/thread/6BNJ3YSEBPHEPGXSAZGBW3TJ64ZGZIHE/

In order to allow "decorator mixins" (most notably dataclass and total_ordering) to implement ABCs, new functionality is needed. I propose a new python function in `abc.py` called `update_abstractmethods`. The function will accept a class and, if the class is an instance of ABCMeta, will update the class's `__abstractmethods__` attribute to not include implemented attributes, and to include new abstractmethods (proposed implementation in thread).

Both dataclass and total_ordering will be modified to call this function on the subject class before returning it, and 3rd-party libraries which implement mixin decorators (like attrs) will be to do the same.

Also, the function can be used as a decorator individually, this is especially useful in cases where 3rd party decorators do not call the function.

----------
components: Library (Lib)
messages: 377769
nosy: avrahami.ben
priority: normal
severity: normal
status: open
title: add update_abstractmethods function to update an ABC's abstract methods
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  1 20:43:26 2020
From: report at bugs.python.org (raybb)
Date: Fri, 02 Oct 2020 00:43:26 +0000
Subject: [New-bugs-announce] [issue41906] logging.config.dictConfig does not
 work with callable filters
Message-ID: <1601599406.74.0.279190575587.issue41906@roundup.psfhosted.org>


New submission from raybb <rayz321z at gmail.com>:

According to the docs here (https://docs.python.org/3/library/logging.html):

"You don?t need to create specialized Filter classes, or use other classes with a filter method: you can use a function (or other callable) as a filter. The filtering logic will check to see if the filter object has a filter attribute: if it does, it?s assumed to be a Filter and its filter() method is called. Otherwise, it?s assumed to be a callable and called with the record as the single parameter."


If I use this code:

def noErrorLogs(param):
    return 1 if param.levelno < 40 else 0

logconfig_dict = {
    'filters': {
        'myfilter': {
            '()': noErrorLogs,
        }
    },
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "level": "DEBUG",
            "stream": "ext://sys.stdout",
            "filters": ["myfilter"]
        }
    },
    "root": {"level": "DEBUG", "handlers": ["console"]},
    "version": 1,
}
dictConfig(logconfig_dict)

I get the error "Unable to configure filter 'myfilter'" because "noErrorLogs() missing 1 required positional argument: 'param'"


However, If I use this code:


def noErrorLogs(param):
    return 1 if param.levelno < 40 else 0

logconfig_dict = {
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "level": "DEBUG",
            "stream": "ext://sys.stdout",
        }
    },
    "root": {"level": "DEBUG", "handlers": ["console"]},
    "version": 1,
}

logging.basicConfig()
dictConfig(logconfig_dict)
l = logging.getLogger()
l.handlers[0].addFilter(noErrorLogs)

Then the filter works correctly.




The bug I am reporting is that when using logging.config.dictConfig you cannot pass in a callable that acts a filter. You can only pass in a class with a filter method or a function that returns a callable filter.

If this is the expected behavior perhaps the docs should make it clear that callables cannot be used with dictConfig.

----------
messages: 377791
nosy: raybb
priority: normal
severity: normal
status: open
title: logging.config.dictConfig does not work with callable filters
type: behavior

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

From report at bugs.python.org  Thu Oct  1 22:38:10 2020
From: report at bugs.python.org (Roger Taylor)
Date: Fri, 02 Oct 2020 02:38:10 +0000
Subject: [New-bugs-announce] [issue41907] Regression in IntFlag behaviour in
 f-string
Message-ID: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>


New submission from Roger Taylor <roger.taylor.email at gmail.com>:

An IntFlag member before 3.8.6 was converted to an integer in an f-string. After 3.8.6, the textual IntFlag class and member name are placed in the interpolated f-string instead of the integer.

3.8.3: f"... {X.F} ..." where X.F = 1 << 4 will give "... 16 ..."
3.8.5: Same
3.8.6: f"... {X.F} ..." where X.F = 1 << 4 will give "... X.F ..."

I have reproduced this on Linux using the version compiled and installed by pyenv, and on Windows using the 32-bit versions from the downloadable standalone installer.

Now I have to locate and go through all my SQL statements and verify that they explicitly convert IntFlag values to integer to avoid the errors introduced by this regression.

----------
components: Interpreter Core
messages: 377793
nosy: rt121212121
priority: normal
severity: normal
status: open
title: Regression in IntFlag behaviour in f-string
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  2 05:56:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Oct 2020 09:56:26 +0000
Subject: [New-bugs-announce] [issue41908] Make IDLE Start Menu entry more
 descriptive
Message-ID: <1601632586.45.0.38147245228.issue41908@roundup.psfhosted.org>


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

A current python-list thread "Problem" is about the difficulties beginners have getting started immediately after installation.  I believe it started with another beginner asking about getting the modify/repair note.  One other thing that came up is that "IDLE", by itself, means nothing to someone who does not know what it is.  So one suggestion was to replace the current
  IDLE (Python 3.9 64 bit)
with something more descriptive.

The current longest entry is
  Python 3.9 Module Docs (64-bit)
which appears to be about as long as possible that fits in the space allowed without being truncated with ... (like "Microsoft Visual Studio 2010 Express").  (The font is proportional, I believe, so a char count does not give an exact measure.)

I propose a new entry for IDLE that is slightly shorter that the apparent maximum.
  IDLE Shell-Editor (3.9 64-bit)

The menu entry is also the initial filename for a desktop shortcut.  For me, after editing is complete, it displays as either


    IDLE
Shell-Edit...
(inactive, 2 lines only) or

  IDLE
Shell-Editor
(3.9 64-bit)
(active, full 3 lines)

I checked that the future '3.10' will not cause a problem.
The popup shortcut comment
"Launches IDLE, the interactive environment for Python 3.9."
nicely complements the proposed title, tying 'IDLE' to 'Python'.
For a taskbar icon, the menu entry is the popup description.
---

macOS: The equivalent of 'Python 3.9' on the start menu is the 'Python 3.9' folder in Finder.  The equivalent of the 'IDLE (Python 3.9 64 bit)' entry is the Python app icon labelled simply 'IDLE' for the IDLE.app startup file. Ned, what would you think of the longer name "IDLE Shell-Editor.app'?  (And maybe add 3.9 somewhere -- I have 3.8 and 3.9 loaded and on the (taskbar) I only know which is which by position.)

----------
assignee: terry.reedy
components: IDLE, Installation, Windows
messages: 377805
nosy: ned.deily, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Make IDLE Start Menu entry more descriptive
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct  2 06:49:51 2020
From: report at bugs.python.org (Ran Benita)
Date: Fri, 02 Oct 2020 10:49:51 +0000
Subject: [New-bugs-announce] [issue41909] Segfault on __getattr__ infinite
 recursion on certain attribute accesses
Message-ID: <1601635791.4.0.685475277421.issue41909@roundup.psfhosted.org>


New submission from Ran Benita <ran at unusedvar.com>:

The following program crashes with a segfault:

class Segfault:
    def __getattr__(self, name):
        self.unknown_attribute

instance = Segfault()
issubclass(instance, int)  # int doesn't matter

Tested with Python 3.7, 3.8, 3.9rc2, and master in debug mode (commit 497126f7ea955ee005e78f2cdd61f175d4fcdbb2).

The program is odd, but this affects pytest (see https://github.com/pytest-dev/pytest/issues/2330).
The class is buggy user code, pytest does the issubclass check.
In pytest there are other code paths which trigger it besides issubclass, but that's the one I am able to quickly reproduce standalone.

Here is the backtrace with python master:

ran at ran:~/src/cpython$ gdb --args ./python segfault.py
Reading symbols from ./python...
(gdb) r
Starting program: /home/ran/src/cpython/python segfault.py

Program received signal SIGSEGV, Segmentation fault.
0x00005555556bc55e in PyGILState_Check () at Python/pystate.c:1353
1353	    if (!PyThread_tss_is_created(&gilstate->autoTSSkey)) {


(gdb) bt 29
#0  0x00005555556bc55e in PyGILState_Check () at Python/pystate.c:1353
#1  0x00005555555fc117 in _PyMem_DebugCheckGIL (func=0x55555581b330 <__func__.10> "_PyMem_DebugMalloc") at Objects/obmalloc.c:2329
#2  _PyMem_DebugMalloc (ctx=0x55555593b140 <_PyMem_Debug+96>, nbytes=185) at Objects/obmalloc.c:2329
#3  0x00005555555fcee8 in PyObject_Malloc (size=<optimized out>) at Objects/obmalloc.c:685
#4  0x000055555562d6f3 in PyUnicode_New (size=136, maxchar=<optimized out>) at Objects/unicodeobject.c:1455
#5  0x00005555556556e7 in _PyUnicodeWriter_PrepareInternal (writer=writer at entry=0x7fffff7ff0c0, length=length at entry=1, maxchar=<optimized out>, maxchar at entry=127)
    at Objects/unicodeobject.c:14004
#6  0x0000555555658439 in _PyUnicodeWriter_WriteASCIIString (writer=writer at entry=0x7fffff7ff0c0, ascii=ascii at entry=0x5555558196c8 "'%.50s' object has no attribute '%U'", 
    len=1) at Objects/unicodeobject.c:14174
#7  0x000055555565a18d in PyUnicode_FromFormatV (format=format at entry=0x5555558196c8 "'%.50s' object has no attribute '%U'", vargs=vargs at entry=0x7fffff7ff170)
    at Objects/unicodeobject.c:3114
#8  0x000055555569646b in _PyErr_FormatV (tstate=0x5555559aa300, exception=<type at remote 0x555555932040>, 
    format=format at entry=0x5555558196c8 "'%.50s' object has no attribute '%U'", vargs=vargs at entry=0x7fffff7ff170) at Python/errors.c:1029
#9  0x0000555555696ff3 in PyErr_Format (exception=<optimized out>, format=format at entry=0x5555558196c8 "'%.50s' object has no attribute '%U'") at Python/errors.c:1071
#10 0x00005555555fa4a5 in _PyObject_GenericGetAttrWithDict (obj=obj at entry=<Segfault at remote 0x7ffff772dd70>, name=name at entry='unknown_attribute', dict=<optimized out>, 
    dict at entry=0x0, suppress=suppress at entry=0) at Objects/object.c:1268
#11 0x00005555555fa96f in PyObject_GenericGetAttr (obj=obj at entry=<Segfault at remote 0x7ffff772dd70>, name=name at entry='unknown_attribute') at Objects/object.c:1281
#12 0x000055555561c3f8 in slot_tp_getattr_hook (self=<Segfault at remote 0x7ffff772dd70>, name='unknown_attribute') at Objects/typeobject.c:6805
#13 0x00005555555f68c2 in PyObject_GetAttr (v=v at entry=<Segfault at remote 0x7ffff772dd70>, name=<optimized out>) at Objects/object.c:891
#14 0x000055555567c254 in _PyEval_EvalFrameDefault (tstate=0x5555559aa300, 
    f=Frame 0x7ffff71cc3b0, for file /home/ran/src/cpython/segfault.py, line 3, in __getattr__ (self=<Segfault at remote 0x7ffff772dd70>, name='unknown_attribute'), 
    throwflag=<optimized out>) at Python/ceval.c:3036
#15 0x00005555555b9d1d in _PyEval_EvalFrame (throwflag=0, 
    f=Frame 0x7ffff71cc3b0, for file /home/ran/src/cpython/segfault.py, line 3, in __getattr__ (self=<Segfault at remote 0x7ffff772dd70>, name='unknown_attribute'), 
    tstate=0x5555559aa300) at ./Include/internal/pycore_ceval.h:40
#16 function_code_fastcall (tstate=0x5555559aa300, co=<optimized out>, args=0x7fffff7ff590, nargs=2, globals=<optimized out>) at Objects/call.c:329
#17 0x00005555555ba67b in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:366
#18 0x000055555576c2d4 in _PyObject_VectorcallTstate (tstate=0x5555559aa300, callable=<function at remote 0x7ffff773c4b0>, args=0x7fffff7ff580, nargsf=2, kwnames=0x0)
    at ./Include/cpython/abstract.h:114
#19 0x000055555576cb87 in method_vectorcall (method=<optimized out>, args=0x7fffff7ff588, nargsf=<optimized out>, kwnames=0x0) at Objects/classobject.c:53
#20 0x00005555556109ac in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x7fffff7ff588, callable=<method at remote 0x7ffff71c8c50>, 
    tstate=0x5555559aa300) at ./Include/cpython/abstract.h:114
#21 PyObject_CallOneArg (arg='unknown_attribute', func=<method at remote 0x7ffff71c8c50>) at ./Include/cpython/abstract.h:184
#22 call_attribute (self=self at entry=<Segfault at remote 0x7ffff772dd70>, attr=<method at remote 0x7ffff71c8c50>, attr at entry=<function at remote 0x7ffff773c4b0>, 
    name=name at entry='unknown_attribute') at Objects/typeobject.c:6771
#23 0x000055555561c44a in slot_tp_getattr_hook (self=<Segfault at remote 0x7ffff772dd70>, name='unknown_attribute') at Objects/typeobject.c:6813
#24 0x00005555555f68c2 in PyObject_GetAttr (v=v at entry=<Segfault at remote 0x7ffff772dd70>, name=<optimized out>) at Objects/object.c:891
#25 0x000055555567c254 in _PyEval_EvalFrameDefault (tstate=0x5555559aa300, 
    f=Frame 0x7ffff71cc200, for file /home/ran/src/cpython/segfault.py, line 3, in __getattr__ (self=<Segfault at remote 0x7ffff772dd70>, name='unknown_attribute'), 
    throwflag=<optimized out>) at Python/ceval.c:3036
#26 0x00005555555b9d1d in _PyEval_EvalFrame (throwflag=0, 
    f=Frame 0x7ffff71cc200, for file /home/ran/src/cpython/segfault.py, line 3, in __getattr__ (self=<Segfault at remote 0x7ffff772dd70>, name='unknown_attribute'), 
    tstate=0x5555559aa300) at ./Include/internal/pycore_ceval.h:40
#27 function_code_fastcall (tstate=0x5555559aa300, co=<optimized out>, args=0x7fffff7ff8b0, nargs=2, globals=<optimized out>) at Objects/call.c:329
#28 0x00005555555ba67b in _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/call.c:366
(More stack frames follow...)



(gdb) py-bt
Traceback (most recent call first):
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
  File "/home/ran/src/cpython/segfault.py", line 3, in __getattr__
    self.unknown_attribute
--Type <RET> for more, q to quit, c to continue without paging--q

----------
components: Interpreter Core
messages: 377807
nosy: bluetech
priority: normal
severity: normal
status: open
title: Segfault on __getattr__ infinite recursion on certain attribute accesses

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

From report at bugs.python.org  Fri Oct  2 11:22:02 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2020 15:22:02 +0000
Subject: [New-bugs-announce] [issue41910] Document that object.__eq__
 implements `a is b`
Message-ID: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>


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

If you look at the data model `for object.__eq__` (https://docs.python.org/3.8/reference/datamodel.html#object.__eq__) you will see that it doesn't mention any actual implementation (unlike for __ne__). But https://github.com/python/cpython/blob/v3.8.3/Objects/typeobject.c#L3834-L3880 shows that object.__eq__ actually does have an implementation of `a is b`/`id(a) == id(b)`.

----------
assignee: docs at python
components: Documentation
messages: 377816
nosy: brett.cannon, docs at python
priority: low
severity: normal
status: open
title: Document that object.__eq__ implements `a is b`
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct  2 11:27:33 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2020 15:27:33 +0000
Subject: [New-bugs-announce] [issue41911] Language reference incorrectly
 says comparison expressions return boolean values
Message-ID: <1601652453.05.0.89373160388.issue41911@roundup.psfhosted.org>


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

https://docs.python.org/3/reference/expressions.html#comparisons claims that "Comparisons yield boolean values: True or False." But that's not necessarily true:

```python
>>> class Spam: 
...  def __eq__(self, _): return 42
... 
>>> Spam() == object()
42
```

That really only happens when an expressions is used in a boolean context like an `if` statements guard expression.

----------
assignee: brett.cannon
components: Documentation
messages: 377817
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Language reference incorrectly says comparison expressions return boolean values
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct  2 14:01:25 2020
From: report at bugs.python.org (Tom Karzes)
Date: Fri, 02 Oct 2020 18:01:25 +0000
Subject: [New-bugs-announce] [issue41912] Long generator chain causes
 segmentation fault
Message-ID: <1601661685.77.0.221830308398.issue41912@roundup.psfhosted.org>


New submission from Tom Karzes <karzes at sonic.net>:

If I create a sufficiently long chain of generators, I encounter a segmentation fault.  For example, the following works as expected:

    % ./gen_bug3.py 10000
    10000
    %

But for sufficiently larger chain lengths, it seg faults:

    % ./gen_bug3.py 20000
    Segmentation fault (core dumped)
    %

and:

    % ./gen_bug3.py 100000
    Segmentation fault (core dumped)
    %

The exact point where it seg faults seems to vary slightly between different invocations of Python, but the range is very narrow for a given Python installation.  I believe the difference is due to slight variations in used memory upon startup.

I can't see any reason why this should happen, and in any case, if there is some limit that I'm exceeding, it should raise an exception rather than core dump.

I'm using:

    3.6.9 (default, Jul 17 2020, 12:50:27)
    [GCC 8.4.0]

on a 64-bit Ubuntu Linux system.

Additional info:  A friend of mine is running 3.7.9 on a Windows system.  In his case, the symptom is that the program produces no output for a sufficiently long generator chain (presumably it's silently crashing).  Additionally, he encounters the problem with much shorter generator chains than I do.  I suspect it's the same underlying problem.

----------
components: Interpreter Core
files: gen_bug3.py
messages: 377826
nosy: karzes
priority: normal
severity: normal
status: open
title: Long generator chain causes segmentation fault
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file49486/gen_bug3.py

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

From report at bugs.python.org  Fri Oct  2 14:57:46 2020
From: report at bugs.python.org (Frederik Rietdijk)
Date: Fri, 02 Oct 2020 18:57:46 +0000
Subject: [New-bugs-announce] [issue41913] EnvBuilder.install_scripts should
 use explicit permissions
Message-ID: <1601665066.98.0.447364183883.issue41913@roundup.psfhosted.org>


New submission from Frederik Rietdijk <fridh at fridh.nl>:

Creating a venv with `python3 -m venv foo` and then reinitializing it with `python3 -m venv foo` fails with a `Error: [Errno 13] Permission denied: '/path/to/cwd/foo/bin/activate.fish'` with the CPython interpreters from Nixpkgs.

The method `EnvBuilder.install_scripts` that is responsible for copying the files, copies the permissions, instead of explicitly stating what permissions are needed. This fails with the Nixpkgs builds of CPython because in Nixpkgs the entire store is made read-only.

Files that need to be copied from the installation during run-time should be explicit about the permissions they require, instead of depending on their current permissions.

----------
messages: 377828
nosy: Frederik Rietdijk
priority: normal
severity: normal
status: open
title: EnvBuilder.install_scripts should use explicit permissions
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct  2 16:39:35 2020
From: report at bugs.python.org (Sumagna Das)
Date: Fri, 02 Oct 2020 20:39:35 +0000
Subject: [New-bugs-announce] [issue41914] test_pdb fails wit
Message-ID: <1601671175.99.0.383994267715.issue41914@roundup.psfhosted.org>


New submission from Sumagna Das <sumagnadas at gmail.com>:

I was thinking about contributing to cpython so i cloned it and followed the tests mentioned on devguide.python.org. When i ran my tests, it failed on two of them: test_pdb and test_ssl. test_ssl had an issue already as i found here. test_pdb failure was the one which i didn't find here. It failed with the following message:

== CPython 3.10.0a0 (heads/master:a937ab45d6, Oct 3 2020, 00:16:29) [GCC 9.3.0]
== Linux-5.4.0-48-generic-x86_64-with-glibc2.31 little-endian
== cwd: /mnt/sda2/github/cpython/build/test_python_21809?
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.52 Run tests in parallel using 2 child processes
0:00:06 load avg: 1.48 [1/1/1] test_pdb failed
test_blocks_at_first_code_line (test.test_pdb.PdbTestCase) ... ok
test_breakpoint (test.test_pdb.PdbTestCase) ... ok
test_errors_in_command (test.test_pdb.PdbTestCase) ... FAIL
test_find_function_empty_file (test.test_pdb.PdbTestCase) ... ok
test_find_function_found (test.test_pdb.PdbTestCase) ... ok
test_find_function_found_with_bom (test.test_pdb.PdbTestCase) ... ok
test_find_function_found_with_encoding_cookie (test.test_pdb.PdbTestCase) ... ok
test_header (test.test_pdb.PdbTestCase) ... ok
test_issue13120 (test.test_pdb.PdbTestCase) ... ok
test_issue13183 (test.test_pdb.PdbTestCase) ... ok
test_issue16180 (test.test_pdb.PdbTestCase) ... ok
test_issue36250 (test.test_pdb.PdbTestCase) ... ok
test_issue7964 (test.test_pdb.PdbTestCase) ... ok
test_module_is_run_as_main (test.test_pdb.PdbTestCase) ... ok
test_module_without_a_main (test.test_pdb.PdbTestCase) ... ok
test_readrc_homedir (test.test_pdb.PdbTestCase) ... ok
test_readrc_kwarg (test.test_pdb.PdbTestCase) ... ok
test_relative_imports (test.test_pdb.PdbTestCase) ... ok
test_relative_imports_on_plain_module (test.test_pdb.PdbTestCase) ... ok
test_run_module (test.test_pdb.PdbTestCase) ... ok
test_run_pdb_with_pdb (test.test_pdb.PdbTestCase) ... ok
test_list_commands (test.test_pdb)
Doctest: test.test_pdb.test_list_commands ... 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_basic_commands (test.test_pdb)
Doctest: test.test_pdb.test_pdb_basic_commands ... ok
test_pdb_breakpoint_commands (test.test_pdb)
Doctest: test.test_pdb.test_pdb_breakpoint_commands ... ok
test_pdb_continue_in_bottomframe (test.test_pdb)
Doctest: test.test_pdb.test_pdb_continue_in_bottomframe ... ok
test_pdb_displayhook (test.test_pdb)
Doctest: test.test_pdb.test_pdb_displayhook ... ok
test_pdb_issue_20766 (test.test_pdb)
Doctest: test.test_pdb.test_pdb_issue_20766 ... ok
test_pdb_next_command_for_asyncgen (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_asyncgen ... ok
test_pdb_next_command_for_coroutine (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_coroutine ... ok
test_pdb_next_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_generator ... ok
test_pdb_next_command_in_generator_for_loop (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_in_generator_for_loop ... ok
test_pdb_next_command_subiterator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_subiterator ... ok
test_pdb_return_command_for_coroutine (test.test_pdb)
Doctest: test.test_pdb.test_pdb_return_command_for_coroutine ... ok
test_pdb_return_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_return_command_for_generator ... ok
test_pdb_run_with_code_object (test.test_pdb)
Doctest: test.test_pdb.test_pdb_run_with_code_object ... ok
test_pdb_run_with_incorrect_argument (test.test_pdb)
Doctest: test.test_pdb.test_pdb_run_with_incorrect_argument ... ok
test_pdb_skip_modules (test.test_pdb)
Doctest: test.test_pdb.test_pdb_skip_modules ... ok
test_pdb_skip_modules_with_callback (test.test_pdb)
Doctest: test.test_pdb.test_pdb_skip_modules_with_callback ... ok
test_pdb_until_command_for_coroutine (test.test_pdb)
Doctest: test.test_pdb.test_pdb_until_command_for_coroutine ... ok
test_pdb_until_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_until_command_for_generator ... ok
test_pdb_whatis_command (test.test_pdb)
Doctest: test.test_pdb.test_pdb_whatis_command ... ok
test_post_mortem (test.test_pdb)
Doctest: test.test_pdb.test_post_mortem ... ok

======================================================================
FAIL: test_errors_in_command (test.test_pdb.PdbTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/sda2/github/cpython/Lib/test/test_pdb.py", line 1650, in test_errors_in_command
    self.assertEqual(stdout.splitlines()[1:], [
AssertionError: Lists differ: ['(Pd[283 chars]efined", 'LEAVING RECURSIVE DEBUGGER', '(Pdb) ', '\x1b[?1034h'] != ['(Pd[283 chars]efined", 'LEAVING RECURSIVE DEBUGGER', '(Pdb) ']

First list contains 1 additional elements.
First extra element 9:
'\x1b[?1034h'

  ['(Pdb) *** SyntaxError: unexpected EOF while parsing',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '*** SyntaxError: unexpected EOF while parsing',
   'LEAVING RECURSIVE DEBUGGER',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '> <string>(1)<module>()',
   "((Pdb)) *** NameError: name 'doesnotexist' is not defined",
   'LEAVING RECURSIVE DEBUGGER',
-  '(Pdb) ',
?          ^

+  '(Pdb) ']
?          ^

-  '\x1b[?1034h']

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

Ran 43 tests in 5.143s

FAILED (failures=1)
test test_pdb failed

== Tests result: FAILURE ==

1 test failed:
    test_pdb

Total duration: 6.8 sec
Tests result: FAILURE

Is this happening only with me?

----------
components: Tests
messages: 377835
nosy: sumagnadas
priority: normal
severity: normal
status: open
title: test_pdb fails wit
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct  2 21:23:47 2020
From: report at bugs.python.org (Ethan Tang US)
Date: Sat, 03 Oct 2020 01:23:47 +0000
Subject: [New-bugs-announce] [issue41915] unittest.mock.create_autospec(Obj,
 instance=True) has self keyword in _spec_signature if Obj
 implements __call__
Message-ID: <1601688227.96.0.0965935424623.issue41915@roundup.psfhosted.org>


New submission from Ethan Tang US <ettang at nvidia.com>:

When an `unittest.mock.create_autospec(Obj, instance=True)` is used, and said Obj implements the `__call__(self, ...)` function, the mocked instance of it will take the full function signature including the `self` argument.

This will then cause an issue when `assert_called_once_with()` or `assert_called_with()` is used. Those two assertions will fail regardless if the arguments used were correct or not. The error message will contain the error: `TypeError: missing a required argument: 'self'`

Here an example of this issue happening

```
from unittest import mock

def Foo(object):

    def __call__(self, a):
        pass

    def bar(self, b):
        ```This is to just compare it with a regular function.```
        pass

foo_mock = mock.create_autospec(Foo, instance=True)
foo_mock(a=1)

foo_mock.assert_called_once_with(a=1)
```

In the example above, the assertion will then fail and raise an error even though the assertion should be correct.

upon inspecting further to understand the issue, this is because `foo_mock._spec_signature` will be `<Signature (self, a)>`.

The existence of `self` in `foo_mock._spec_signature` will cause this error.

As compared to the method `foo_mock.bar._spec_signature`, it will only be `<Signature (b)>`.

The reason for me posting this issue is that development with the Keras library heavily uses __call__ in their API and therefore it is hard to mock the APIs if such issue exists. One work around would be iterating through its `called_args_list`.

----------
components: Library (Lib)
messages: 377846
nosy: ettang
priority: normal
severity: normal
status: open
title: unittest.mock.create_autospec(Obj, instance=True) has self keyword in _spec_signature if Obj implements __call__
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct  3 03:20:28 2020
From: report at bugs.python.org (Dustin Spicuzza)
Date: Sat, 03 Oct 2020 07:20:28 +0000
Subject: [New-bugs-announce] [issue41916] cxx pthread check is not
 overrideable
Message-ID: <1601709628.96.0.95457003563.issue41916@roundup.psfhosted.org>


New submission from Dustin Spicuzza <dustin at virtualroadside.com>:

I'm cross-compiling python to ARM, following instructions from the crossenv project @ https://crossenv.readthedocs.io/en/latest/quickstart.html#build-or-obtain-host-python

I was getting pthread related errors when using cross-built extension modules. I realized the issue was that distutils wasn't passing -pthread to gcc.

On my native python (Fedora 32 Python 3.8):

>>> import pprint, distutils.sysconfig
>>> pprint.pprint({i: distutils.sysconfig.get_config_vars(i)[0] for i in ('CC', 'CXX', 'LDSHARED')})
{'CC': 'gcc -pthread',
 'CXX': 'g++ -pthread',
 'LDSHARED': 'gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now  '
             '-g  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now  -g'}

In my cross-compiled python environment:

>>> import pprint, distutils.sysconfig
>>> pprint.pprint({i: distutils.sysconfig.get_config_vars(i)[0] for i in ('CC', 'CXX', 'LDSHARED')})
{'CC': 'arm-frc2020-linux-gnueabi-gcc',
 'CXX': 'arm-frc2020-linux-gnueabi-c++',
 'LDSHARED': 'arm-frc2020-linux-gnueabi-gcc -shared'}

As you can see, no -pthread flag. I went digging in the configure script and found this comment in configure.ac:2110:

# Some compilers won't report that they do not support -pthread,
# so we need to run a program to see whether it really made the
# function available.

... well, that doesn't work when cross-compiling. I looked at some other variables set to override things for cross compiling, and tried adding "ac_cv_pthread_is_default=no ac_cv_pthread=yes ac_cv_cxx_thread=yes" to my cross-compile ./configure, and it's closer:

>>> import pprint, distutils.sysconfig
>>> pprint.pprint({i: distutils.sysconfig.get_config_vars(i)[0] for i in ('CC', 'CXX', 'LDSHARED')})
{'CC': 'arm-frc2020-linux-gnueabi-gcc -pthread',
 'CXX': 'arm-frc2020-linux-gnueabi-c++',
 'LDSHARED': 'arm-frc2020-linux-gnueabi-gcc -pthread -shared'}

Closer, but not there yet! It appears that the $ac_cv_cxx_thread is not externally settable (unlike ac_cv_pthread), which I guess is because it's not wrapped in a AC_CACHE_VAL macro?

It seems that the right fix would be for someone to use AC_CACHE_VAL to allow $ac_cv_cxx_thread to be set externally? I'm happy to cargo cult some code from other parts of configure.ac and make a PR for it, but it's not immediately clear (a) what bad side effects this could cause and (b) what the best mechanism to use to regenerate configure et al is?

----------
components: Cross-Build
messages: 377858
nosy: Alex.Willmer, virtuald
priority: normal
severity: normal
status: open
title: cxx pthread check is not overrideable
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct  3 03:49:25 2020
From: report at bugs.python.org (ullix)
Date: Sat, 03 Oct 2020 07:49:25 +0000
Subject: [New-bugs-announce] [issue41917] Python 3.9rc2 fails to install
 matplotlib
Message-ID: <1601711365.63.0.761607861812.issue41917@roundup.psfhosted.org>


New submission from ullix <ullix at urkam.de>:

Installing matplotlib via: python3 -m pip install -U matplotlib
fails because kiwisolver cannot be installed. Among a lot of error output is: WARNING: The wheel package is not available.

Not having matplotlib is a MAJOR hurdle for many!


Sstem: Ubuntu 16.04 with Python 3.9rc2 installed from deadsnakes repository (http://ppa.launchpad.net/deadsnakes/ppa/ubuntu/)

----------
components: Installation
messages: 377859
nosy: ullix
priority: normal
severity: normal
status: open
title: Python 3.9rc2 fails to install matplotlib
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct  3 05:06:44 2020
From: report at bugs.python.org (Quentin Peter)
Date: Sat, 03 Oct 2020 09:06:44 +0000
Subject: [New-bugs-announce] [issue41918] exec fails to take locals into
 account when running list comprehensions
Message-ID: <1601716004.0.0.802801393199.issue41918@roundup.psfhosted.org>


New submission from Quentin Peter <qpeter at bluewin.ch>:

The exec function fails to take locals into account when executing a list comprehension:
```
Python 3.7.7 (default, Mar 10 2020, 15:43:33) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exec(compile('[my_var for i in range(1)]\n', '<stdin>', 'single'), {**globals(), "my_var": 0}, None)
[0]
>>> exec(compile('[my_var for i in range(1)]\n', '<stdin>', 'single'), globals(), {"my_var": 0})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
NameError: name 'my_var' is not defined
>>> 
```
This is the cause of https://bugs.python.org/issue21161

----------
messages: 377862
nosy: qpeter
priority: normal
severity: normal
status: open
title: exec fails to take locals into account when running list comprehensions
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sat Oct  3 05:37:07 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 03 Oct 2020 09:37:07 +0000
Subject: [New-bugs-announce] [issue41919] Move the codecs' register
 operation to testcases
Message-ID: <1601717827.7.0.637294336769.issue41919@roundup.psfhosted.org>


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

After PR22360 merged, we can move the codecs' register operation to testcases.

----------
components: Tests
messages: 377863
nosy: shihai1991, vstinner
priority: normal
severity: normal
status: open
title: Move the codecs' register operation to testcases
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct  3 07:39:41 2020
From: report at bugs.python.org (Leonard Schwennesen)
Date: Sat, 03 Oct 2020 11:39:41 +0000
Subject: [New-bugs-announce] [issue41920] Weird add operation of "0.2222 +
 0.1111"
Message-ID: <1601725181.53.0.727469935565.issue41920@roundup.psfhosted.org>


New submission from Leonard Schwennesen <l.schwennesen at gmx.net>:

If I add 0.2222 + 0.1111 in the python cli I get the value 0.33330000000000004 and not 0.3333. Also the other way around.
But if I enter for example 0.22222+0.11111 I get 0.33333 so that's right.
Here are a few examples I tested that working properly:

>>> 0.22+0.11
0.33
>>> 0.222+0.111
0.333
>>> 0.22222+0.11111
0.33333
>>> 0.3333+0.7777
1.111
>>> 0.3333+0.6666
0.9999
>>> 0.3333+0.3333
0.6666
>>> 0.6666+0.1111
0.7777
>>> 0.2222+0.3333
0.5555

Python 3.8.5
[GCC 10.2.0] on linux

I also tested that in a newly setup VM, same issue

----------
messages: 377871
nosy: ungedummt
priority: normal
severity: normal
status: open
title: Weird add operation of "0.2222 + 0.1111"
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct  3 11:12:49 2020
From: report at bugs.python.org (yeting li)
Date: Sat, 03 Oct 2020 15:12:49 +0000
Subject: [New-bugs-announce] [issue41921] REDoS in parseentities
Message-ID: <1601737969.46.0.495788645161.issue41921@roundup.psfhosted.org>


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

Hi,

I find this regex '<!ENTITY +(\w+) +CDATA +"([^"]+)" +-- +((?:.|\n)+?) *-->' may be stucked by input.
The vulnerable regex is located in
https://github.com/python/cpython/blob/8d21aa21f2cbc6d50aab3f420bb23be1d081dac4/Tools/scripts/parseentities.py#L18

The ReDOS vulnerability of the regex is mainly due to the sub-pattern ' +((?:.|\n)+?) *'
and can be exploited with the following string
'<!ENTITY a CDATA "a" -- ' + ' ' * 5000

You can execute the following code to reproduce ReDos


from Tools.scripts.parseentities import parse
from time import perf_counter

for i in range(0, 10000):
    ATTACK = '<!ENTITY a CDATA "a" -- ' + ' ' * i * 100
    LEN = len(ATTACK)
    BEGIN = perf_counter()
    parse(ATTACK)
    DURATION = perf_counter() - BEGIN
    print(f"{LEN}: took {DURATION} seconds!")





Looking forward for your response?!

Best,
Yeting Li

----------
components: Demos and Tools
messages: 377885
nosy: yetingli
priority: normal
severity: normal
status: open
title: REDoS in parseentities
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct  3 12:00:56 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 03 Oct 2020 16:00:56 +0000
Subject: [New-bugs-announce] [issue41922] Use PEP 590 vectorcall to speed up
 calls to reversed()
Message-ID: <1601740856.71.0.650184607578.issue41922@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

reversed is also a very well-used type.
if shows 10+ percent performance improvement from baseline and this metric.
And this improvement looks acceptable from viewing builtin types which are applied PEP 590 (frozenset, list, set, dict)  

reversed creation + for loop
Mean +- std dev: [reversed_master] 157 ns +- 4 ns -> [reversed_opt] 139 ns +- 2 ns: 1.13x faster (-11%)

reversed creation
Mean +- std dev: [reversed2_master] 118 ns +- 2 ns -> [reversed2_opt] 101 ns +- 2 ns: 1.18x faster (-15%)

----------
components: Interpreter Core
files: bench_reversed.py
messages: 377889
nosy: corona10, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Use PEP 590 vectorcall to speed up calls to reversed()
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49488/bench_reversed.py

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

From report at bugs.python.org  Sat Oct  3 12:16:30 2020
From: report at bugs.python.org (Mikhail Golubev)
Date: Sat, 03 Oct 2020 16:16:30 +0000
Subject: [New-bugs-announce] [issue41923] Add PEP 613 typing.TypeAlias to
 the standard library
Message-ID: <1601741790.03.0.822782590759.issue41923@roundup.psfhosted.org>


New submission from Mikhail Golubev <mikhail.golubev at jetbrains.com>:

TypeAlias is already included in typing_extensions package, making it available for pre-3.10 versions of Python. I'd like port this implementation to the upstream version of typing.

----------
components: Library (Lib)
messages: 377890
nosy: mikhail.golubev
priority: normal
severity: normal
status: open
title: Add PEP 613 typing.TypeAlias to the standard library
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct  3 20:54:49 2020
From: report at bugs.python.org (ThePokestarFan)
Date: Sun, 04 Oct 2020 00:54:49 +0000
Subject: [New-bugs-announce] [issue41924] TextWrap's wrap method throws
 unhelpful error on bytes object
Message-ID: <1601772889.68.0.485991506579.issue41924@roundup.psfhosted.org>


New submission from ThePokestarFan <sarkaraoyan at gmail.com>:

The wrap() method of the TextWrapper class (and the module-level wrap method) throws an unhelpful TypeError upon getting a bytes object.

----------
components: Library (Lib)
files: traceback.txt
messages: 377910
nosy: ThePokestarFan
priority: normal
severity: normal
status: open
title: TextWrap's wrap method throws unhelpful error on bytes object
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49489/traceback.txt

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

From report at bugs.python.org  Sat Oct  3 23:28:41 2020
From: report at bugs.python.org (Chris Tse)
Date: Sun, 04 Oct 2020 03:28:41 +0000
Subject: [New-bugs-announce] [issue41925] Lowercase path to python.exe in
 pip.exe from venv is throwing error
Message-ID: <1601782121.26.0.581028489128.issue41925@roundup.psfhosted.org>


New submission from Chris Tse <christse at hey.com>:

Following up on https://bugs.python.org/issue37369 as it was advised to open a new issue regarding case sensitivity.

I am on Windows 10 running Version 10.0.19041 Build 19041. I am experiencing the same problem in that issue when using venv on Powershell. 
The path to python.exe in the pip.exe generated by venv is all lowercase, which is the source of this error.
After activating the venv with Activate.ps1 and attempting to use pip, I get the following error, while activate.bat on cmd works fine:

Fatal error in launcher: Unable to create process using '"c:\users\chris\code\project\myenv\scripts\python.exe"  "C:\Users\chris\code\project\myenv\Scripts\pip.exe" ': The system cannot find the file specified.


Full steps to reproduce:
  1. Install Python 3.8.6 from python.org (ticking add to PATH option in installer)
  2. Open Powershell (via both native Powershell app or the new Windows Terminal) and verify that `python` is bound to the correct Version
  3. Run `python -m venv myenv`
  4. Run `.\myenv\Scripts\Activate.ps1`
  5. Run `pip`

Expected behavior: Get the pip usage commands list

Actual behavior: Get the above Fatal error

Notes:
I did not explicitly set case sensitivity on my machine. All my drives are formatted as NTFS, but should not be case sensitive, which can be confirmed by fsutils:

> fsutil.exe file queryCaseSensitiveInfo C:\
Case sensitive attribute on directory C:\ is disabled.

Attempting to actually call that python.exe using the full lowercase path throws a similar error. 

Someone I know who has been helping with debugging this ran the Scripts\activate script successfully on the same version of Powershell as mine (5.1.19041.1) which should be meant for use on bash. I however was not able to do so.

----------
components: Windows
messages: 377916
nosy: chris-tse, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Lowercase path to python.exe in pip.exe from venv is throwing error
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct  4 07:03:56 2020
From: report at bugs.python.org (=?utf-8?b?0JTQttC+0L0g0KHQvNC40YI=?=)
Date: Sun, 04 Oct 2020 11:03:56 +0000
Subject: [New-bugs-announce] [issue41926] Unpredictable behavior when
 parsing xml. (xml.etree.ElementTree.iterparse)
Message-ID: <1601809436.34.0.291596574869.issue41926@roundup.psfhosted.org>


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

Data is lost when parsing large files.
I have prepared 5 test files for different cases.
With their help, I learned that losses are not accidental.
In example.xml, when going to iteration 717 (i = 717), the data is lost.

In the rest of the files, I learned that data loss occurs when the number of characters changes. It looks like some kind of buffer overflow.
In example5.xml I am using randomly generated data using a generator.py.

Several xml files have been prepared to show that this is not an error in the input data, but a problem in the library itself.

I tried to trace the cause of the occurrence, and came to the conclusion that the bug lies in the compiled file.

In the ElementTree.py library file, the line
"events = self._events_queue" 
returns an empty list. This can be seen at iteration 717 in example.xml.

----------
components: XML
messages: 377928
nosy: kibertitan
priority: normal
severity: normal
status: open
title: Unpredictable behavior when parsing xml. (xml.etree.ElementTree.iterparse)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct  4 07:11:57 2020
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQm9Cw0LrQtdC10LI=?=)
Date: Sun, 04 Oct 2020 11:11:57 +0000
Subject: [New-bugs-announce] [issue41927] Why is there no documentation in
 Russian?
Message-ID: <1601809917.86.0.842552109928.issue41927@roundup.psfhosted.org>


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

Is this a racist policy of the site management? For so much time, not even for 2.7. I'm sure there were a lot of suggestions to add. Aren't you ashamed?

----------
assignee: docs at python
components: Documentation
messages: 377930
nosy: docs at python, lakeevboris
priority: normal
severity: normal
status: open
title: Why is there no documentation in Russian?
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct  4 07:21:41 2020
From: report at bugs.python.org (Ivan Sorokin)
Date: Sun, 04 Oct 2020 11:21:41 +0000
Subject: [New-bugs-announce] [issue41928] ZipFile does not supports Unicode
 Path Extra Field (0x7075) zip header field
Message-ID: <1601810501.41.0.603959888811.issue41928@roundup.psfhosted.org>


New submission from Ivan Sorokin <ivan.sorokin.tech at gmail.com>:

See attached sample. Well-known unzip command line tool lists its contents correctly:

$ unzip -l 23.zip
Archive:  23.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
    81408  2012-10-23 19:03   ?' ???? ??06 ??????? ???? (???).xls
---------                     -------
    81408                     1 file

But ZipFile lists the same file inside this archive as
?' ???? ??06 ??????? ???? (???).xls

It's because ZipFile completely ignores Unicode Path Extra Field (0x7075) zip header field.

See .ZIP specification for details on this field meaning and usage:
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

----------
components: Library (Lib)
files: 23.zip
messages: 377931
nosy: ivan.sorokin.tech
priority: normal
severity: normal
status: open
title: ZipFile does not supports Unicode Path Extra Field (0x7075) zip header field
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49491/23.zip

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

From report at bugs.python.org  Sun Oct  4 07:36:22 2020
From: report at bugs.python.org (Ivan Sorokin)
Date: Sun, 04 Oct 2020 11:36:22 +0000
Subject: [New-bugs-announce] [issue41929] Detect OEM code page for zip
 archives in ZipFile based on system locale
Message-ID: <1601811382.76.0.398158982461.issue41929@roundup.psfhosted.org>


New submission from Ivan Sorokin <ivan.sorokin.tech at gmail.com>:

ZipFile has problems with filename charset in .zip archives having filenames charset encoded in OEM code page.

ZipFile assumes that OEM code page always means "cp437". Actually many popular .zip packers (for example, Windows internal "zip folders" tool) use OEM code page corresponding to system locale to write file names in .zip files.

To read such files correctly we should detect correct OEM code page from system locale instead of sticking to cp437.

Here is locale-to-oem-code-page conversion table, generated from Wine source code:
https://github.com/unxed/oemcp/blob/master/oemcp.txt

Sample archive is attached. The file inside should be extracted as "????? ????????? ????????.txt" when ru_RU system locale is set.

----------
components: Library (Lib)
files: windows_cyrillic.zip
messages: 377932
nosy: ivan.sorokin.tech
priority: normal
severity: normal
status: open
title: Detect OEM code page for zip archives in ZipFile based on system locale
versions: Python 3.10
Added file: https://bugs.python.org/file49492/windows_cyrillic.zip

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

From report at bugs.python.org  Sun Oct  4 08:05:11 2020
From: report at bugs.python.org (Kerrick Staley)
Date: Sun, 04 Oct 2020 12:05:11 +0000
Subject: [New-bugs-announce] [issue41930] Wrap sqlite3_serialize API in
 sqlite3 module
Message-ID: <1601813111.02.0.183059099502.issue41930@roundup.psfhosted.org>


New submission from Kerrick Staley <kerrick at kerrickstaley.com>:

It would be useful to provide a wrapper (in the Python sqlite3 stdlib module) for the sqlite3_serialize API. This API allows you to get a database's content as a byte string, as if you had called open('foo.sqlite3', 'rb').read(). sqlite3_serialize can even be used for :memory: databases, which I think is the most interesting use-case.

Concretely, I'd propose adding a .serialize() method on sqlite3.Connection objects that returns a bytes object representing the serialized database. It would be similar to the .iterdump() method except that it would use the binary format instead of the text format, and it would return all the data at once instead of an iterator (because that's how the underlying sqlite API works).

----------
components: Library (Lib)
messages: 377935
nosy: Kerrick Staley
priority: normal
severity: normal
status: open
title: Wrap sqlite3_serialize API in sqlite3 module
type: enhancement

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

From report at bugs.python.org  Sun Oct  4 09:44:57 2020
From: report at bugs.python.org (=?utf-8?b?4K6u4K6p4K+L4K6c4K+N4K6V4K+B4K6u4K6+4K6w4K+NIOCuquCutOCuqQ==?= =?utf-8?b?4K6/4K6a4K+N4K6a4K6+4K6u4K6/?=)
Date: Sun, 04 Oct 2020 13:44:57 +0000
Subject: [New-bugs-announce] [issue41931] Make dict(object) return its
 attribute __dict__
Message-ID: <1601819097.88.0.92979678916.issue41931@roundup.psfhosted.org>


Change by ??????????? ?????????? <smartmanoj42857 at gmail.com>:


----------
nosy: SmartManoj
priority: normal
severity: normal
status: open
title: Make dict(object) return its attribute __dict__
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct  4 11:56:03 2020
From: report at bugs.python.org (berthin)
Date: Sun, 04 Oct 2020 15:56:03 +0000
Subject: [New-bugs-announce] [issue41932] Incorrect struct definition with
 bitfields
Message-ID: <1601826963.62.0.914106725495.issue41932@roundup.psfhosted.org>


New submission from berthin <berthin_37 at hotmail.com>:

Hi all,

I found one issue related to bitfields and ctypes, and although there is a similar issue already opened (https://bugs.python.org/issue29753), that only covers the case with pragmas. 

Please, consider the following scenario:

>>> from ctypes import *
>>> class X(Structure):
...     _fields_ = [("a", c_uint8, 8), ("b", c_uint8, 8), ("c", c_uint32, 16)]
...
>>> sizeof(X)
5


Which seems to be incorrect, because what natively C does is to generate a 4bytes struct.

root at 0bc6a647abaa:/target/cpython-fix# cat sample.c

#include <stdio.h>
#include <stdint.h>
struct X { 
    uint8_t a; 
    uint8_t b; 
    uint32_t c:16;
} X;

int main() { 
    printf("%u\n", sizeof(X)); 
}

root at 0bc6a647abaa:/target/cpython-fix# gcc sample.c -o a && ./a
4

Also, if I use different databtypes I get what I expect (a struct of 4 bytes).

>>> X = type('X', (Structure,), {'_fields_': [('a', c_uint32, 8), ('b', c_uint32, 8), ('c', c_uint32, 16)]})
>>> sizeof(X)
4
>>> X = type('X', (Structure,), {'_fields_': [('a', c_uint16, 8), ('b', c_uint16, 8), ('c', c_uint16, 16)]})
>>> sizeof(X)
4
>>> X = type('X', (Structure,), {'_fields_': [('a', c_uint8, 8), ('b', c_uint8, 8), ('c', c_uint16, 16)]})
>>> sizeof(X)
4

I tried to debug a little bit, adding some prints before and after calling *PyCField_FromDesc* in *Modules/_ctypes/stgdict.c:L603*.=, if someone wants to look at it, the logs are attached / one log file per each test, using the following gdb init:

# before
break stgdict.c:601
commands
p field_size
p bitofs
p size
p align
p *dict
continue
end


# after
break stgdict.c:617
commands
p field_size
p bitofs
p size
p align
p *(CFieldObject*) prop
continue
end

Hope someone could spot the issue, I will also try to investigate it by my own.

Best,

P.S. For the tests, I worked on top of bpo-29753 (https://github.com/python/cpython/pull/19850)

----------
components: ctypes
files: bitfields.zip
messages: 377953
nosy: FFY00, berthin
priority: normal
severity: normal
status: open
title: Incorrect struct definition with bitfields
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49493/bitfields.zip

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

From report at bugs.python.org  Sun Oct  4 12:20:21 2020
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Oct 2020 16:20:21 +0000
Subject: [New-bugs-announce] [issue41933] Wording of s * n in Common
 Sequence Operations is not optimal
Message-ID: <1601828421.16.0.497838866676.issue41933@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

As reported by Graham Ewart on docs@,

in https://docs.python.org/3/library/stdtypes.html#common-sequence-operations:

s * n or n * s | equivalent to adding s to itself n times

is badly worded. In fact it's more like n-1 times, but yet it's not adding s to itself.

I'd go for "n times the s sequence" or "n copies of the s sequence" instead, which both avoid the "n-1" and the "to itself" parts.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 377958
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: Wording of s * n in Common Sequence Operations is not optimal

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

From report at bugs.python.org  Sun Oct  4 16:55:49 2020
From: report at bugs.python.org (Hadi Alqattan)
Date: Sun, 04 Oct 2020 20:55:49 +0000
Subject: [New-bugs-announce] [issue41934] Add `has` method to `pathlib.Path`
 class.
Message-ID: <1601844949.96.0.502154484119.issue41934@roundup.psfhosted.org>


New submission from Hadi Alqattan <alqattanhadizaki at gmail.com>:

Adding a new method to `pathlib.Path` class, `has` method is a method that can determine if the `Path` object has a specific file/dir or not.

Assume that we have a `Path` object for this `project/` directory:
```
project/
  main.py
  __init__.py
  utils/
```
and we want to know if the project directory has `main.py` or not, after adding this method we will be able to do this:
```
from pathlib import Path

project_path = Path("./project")

if project_path.has("main.py"):
    pass  # do something.
```

----------
components: Library (Lib)
messages: 377973
nosy: hadialqattan
priority: normal
severity: normal
status: open
title: Add `has` method to `pathlib.Path` class.
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct  4 17:22:09 2020
From: report at bugs.python.org (Hadi Alqattan)
Date: Sun, 04 Oct 2020 21:22:09 +0000
Subject: [New-bugs-announce] [issue41935] Add binary operator!
Message-ID: <1601846529.24.0.0764932773138.issue41935@roundup.psfhosted.org>


New submission from Hadi Alqattan <alqattanhadizaki at gmail.com>:

What are your opinions about adding a binary operator to Python in order to make this code possible?
```
my_counter = 0

for i in rage(1000):
    my_counter += 1 if (i % 2) == 0
```

----------
components: Interpreter Core
messages: 377976
nosy: hadialqattan
priority: normal
severity: normal
status: open
title: Add binary operator!
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct  4 18:20:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Oct 2020 22:20:31 +0000
Subject: [New-bugs-announce] [issue41936] Remove macros
 Py_ALLOW_RECURSION/Py_END_ALLOW_RECURSION
Message-ID: <1601850031.67.0.853880469279.issue41936@roundup.psfhosted.org>


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

Macros Py_ALLOW_RECURSION and Py_END_ALLOW_RECURSION together with field recursion_critical of the PyInterpreterState structure were added in 5b222135f8d2492713994f2cb003980e87ce6a72 but were never documented. It seems that the reason of adding them was to work around the fact that PyDict_GetItem() can silence any exception including recursion error. But PyDict_GetItem() no longer used in that code and the macros are also no longer used (see issue41909).

GvR proposed to remove these macros. I think that recursion_critical can be removed too.

----------
components: C API
messages: 377978
nosy: gvanrossum, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Remove macros Py_ALLOW_RECURSION/Py_END_ALLOW_RECURSION
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct  4 19:14:07 2020
From: report at bugs.python.org (twoone3)
Date: Sun, 04 Oct 2020 23:14:07 +0000
Subject: [New-bugs-announce] [issue41937] how to use cpython O&
Message-ID: <1601853247.59.0.581530220045.issue41937@roundup.psfhosted.org>


New submission from twoone3 <3197653242 at qq.com>:

When I use'O&' to parse the parameters, I have never succeeded, I hope I can give a demo

----------
files: Screenshot_2020_1005_070639.png
messages: 377983
nosy: twoone3
priority: normal
severity: normal
status: open
title: how to use cpython O&
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49494/Screenshot_2020_1005_070639.png

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

From report at bugs.python.org  Sun Oct  4 22:02:57 2020
From: report at bugs.python.org (Kaushal Rohit)
Date: Mon, 05 Oct 2020 02:02:57 +0000
Subject: [New-bugs-announce] [issue41938] concurrent.futures.wait calls
 len() on an possible iterable
Message-ID: <1601863377.27.0.411836826133.issue41938@roundup.psfhosted.org>


New submission from Kaushal Rohit <rohit.kg98 at gmail.com>:

`fs` argument could be an iterable, and calling len on it would raise an Exception.

We are converting `fs` into a set anyways for set difference, and that too twice. we can just put an `fs = set(fs)`.

Let me know if we choose to go with that and I will make a PR ASAP.

Thanks.

----------
components: Library (Lib)
messages: 377991
nosy: rohitkg98
priority: normal
severity: normal
status: open
title: concurrent.futures.wait calls len() on an possible iterable
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct  5 03:01:03 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Oct 2020 07:01:03 +0000
Subject: [New-bugs-announce] [issue41939] 3.9.0 test_site warning:
 "urllib.requests._opener was modified by test_site"
Message-ID: <1601881263.18.0.474767166198.issue41939@roundup.psfhosted.org>


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

For 3.9.0, test_site fails with an env changed warning:

Warning -- urllib.requests._opener was modified by test_site
  Before: None
  After:  <urllib.request.OpenerDirector object at 0xb76f4f88>
test_site failed (env changed)

== Tests result: SUCCESS ==

1 test altered the execution environment:
    test_site

The problem occurs in test_site's test_license_exists_at_url test and was introduced by the changes in Issue37421: "Some tests leak temporary files".

This failure has not been noticed up to now because test_license_exists_at_url is skipped unless the build being tested is for a released branch, which is about to happen for 3.9 with the 3.9.0 release.  The test failure can be reproduced on any build by commenting out Lib/test_site.py lines 503-504:

    @unittest.skipUnless(sys.version_info[3] == 'final',
                         'only for released versions')

Setting to "deferred blocker" status for release manager evaluation.

----------
components: Tests
messages: 377995
nosy: lukasz.langa, ned.deily, vstinner
priority: deferred blocker
severity: normal
status: open
title: 3.9.0 test_site warning: "urllib.requests._opener was modified by test_site"
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Oct  5 04:48:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Oct 2020 08:48:07 +0000
Subject: [New-bugs-announce] [issue41940] AMD64 Debian root 3.x: tests fail
 because downloaded files start with: <!DOCTYPE
Message-ID: <1601887687.95.0.739602877312.issue41940@roundup.psfhosted.org>


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

Why do downloaded files start with <!DOCTYPE?

AMD64 Debian root 3.x:
https://buildbot.python.org/all/#/builders/345/builds/132

5 tests failed:
    test_codecmaps_cn test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_hashlib

I'm not sure if all failures are download issues.


Examples:

ERROR: test_mapping_file (test.test_codecmaps_kr.TestCP949Map)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/multibytecodec_support.py", line 305, in test_mapping_file
    self._test_mapping_file_plain()
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/multibytecodec_support.py", line 319, in _test_mapping_file_plain
    csetval = eval(data[0])
  File "<string>", line 1
    <!DOCTYPE
    ^
SyntaxError: invalid syntax


ERROR: test_named_sequences_full (test.test_ucn.UnicodeNamesTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_ucn.py", line 181, in test_named_sequences_full
    testdata = support.open_urlresource(url, encoding="utf-8",
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 540, in open_urlresource
    raise TestFailed('invalid resource %r' % fn)
test.support.TestFailed: invalid resource '/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/data/NamedSequences.txt'


ERROR: test_blake2b_vectors (test.test_hashlib.HashLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_hashlib.py", line 733, in test_blake2b_vectors
    for msg, key, md in read_vectors('blake2b'):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_hashlib.py", line 85, in read_vectors
    parts[0] = bytes.fromhex(parts[0])
ValueError: non-hexadecimal number found in fromhex() arg at position 0



AMD64 Debian root 3.9 has similar issues.

----------
components: Tests
messages: 378003
nosy: vstinner
priority: normal
severity: normal
status: open
title: AMD64 Debian root 3.x: tests fail because downloaded files start with: <!DOCTYPE
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct  5 04:51:42 2020
From: report at bugs.python.org (twoone3)
Date: Mon, 05 Oct 2020 08:51:42 +0000
Subject: [New-bugs-announce] [issue41941] Py_Initialize affects the console
Message-ID: <1601887902.24.0.789073375797.issue41941@roundup.psfhosted.org>


New submission from twoone3 <3197653242 at qq.com>:

When I set Py_LegacyWindowsStdioFlag to 0, after Py_Initialize, the console will forcibly change what encoding is displayed. At this time, my standard stream output is utf-8, py's print is utf-8, chcp 65001 is useless, and still garbled.  When I set Py_LegacyWindowsStdioFlag to 1, the console encoding is mbcs, the standard stream output is UTF-8 and not garbled, but the print of py is gbk encoding, and my system is Windows server 2016. I hope that Py_Initialize will not affect the console in subsequent versions.  Do any behavior, I suggest you test the coding problem in Chinese

----------
components: C API
messages: 378004
nosy: twoone3
priority: normal
severity: normal
status: open
title: Py_Initialize affects the console
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct  5 06:33:27 2020
From: report at bugs.python.org (chienpingtsung)
Date: Mon, 05 Oct 2020 10:33:27 +0000
Subject: [New-bugs-announce] [issue41942] Add if condition for 'for loop'
Message-ID: <1601894007.96.0.390965204143.issue41942@roundup.psfhosted.org>


New submission from chienpingtsung <jianpingzong at outlook.com>:

'for loop' always been used as follow code:

arr = [...]
for e in arr:
    if not condition(e):
        continue
    ...

What if be written just like 'list expression', would it be more explicit?

for e in arr if condition(e):
    pass

----------
components: Interpreter Core
messages: 378015
nosy: chienpingtsung
priority: normal
severity: normal
status: open
title: Add if condition for 'for loop'
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct  5 10:40:00 2020
From: report at bugs.python.org (mrbean-bremen)
Date: Mon, 05 Oct 2020 14:40:00 +0000
Subject: [New-bugs-announce] [issue41943] unittest.assertLogs passes
 unexpectedly
Message-ID: <1601908800.0.0.297130696317.issue41943@roundup.psfhosted.org>


New submission from mrbean-bremen <hansemrbean at googlemail.com>:

Related to https://bugs.python.org/issue41898, creating a new issue after the discussion with Irit Katriel on StackOverflow (https://stackoverflow.com/a/64142338/12480730).

Consider the following:

import logging
import unittest

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)


class TestLogging(unittest.TestCase):
    def test_logging(self):
        with self.assertLogs(level=logging.WARNING):
            logger.info('foo')

>From the docs:
The test passes if at least one message emitted inside the with block matches the logger and level conditions, otherwise it fails.

This means that this test should fail (nothing has been logged at warning level or above), but it passes. 

The reason is that in the assertLogs context manager, the log level of the passed logger is temporarily set to the passed level, and if no logging has happened on exit, the test will fail. 
If no logger is passed into the call, the temporary log level is set in the root level. If any descendant logger has it's own log level set (as in this example to INFO), this logger will still log at it's own level, and the test will pass. 

This will always happen on the condition that a descendent of the passed logger has it's own log level set that is smaller than the asserted level, and it does some logging at this level inside the assertLog context manager.

----------
components: Library (Lib)
messages: 378035
nosy: mrbean-bremen
priority: normal
severity: normal
status: open
title: unittest.assertLogs passes unexpectedly
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct  5 10:40:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2020 14:40:52 +0000
Subject: [New-bugs-announce] [issue41944] Python testsuite calls eval() on
 content received via HTTP
Message-ID: <1601908852.29.0.0266876682235.issue41944@roundup.psfhosted.org>


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

As was reported by Florian Bruhin, Python testsuite calls eval() on content received via HTTP (in Lib/test/multibytecodec_support.py).

----------
components: Tests
messages: 378036
nosy: The Compiler, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Python testsuite calls eval() on content received via HTTP
type: security
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct  5 11:19:46 2020
From: report at bugs.python.org (Jan Novak)
Date: Mon, 05 Oct 2020 15:19:46 +0000
Subject: [New-bugs-announce] [issue41945] http.cookies.SimpleCookie.parse
 error after [keys]
Message-ID: <1601911186.95.0.178044136501.issue41945@roundup.psfhosted.org>


New submission from Jan Novak <xnovakj at seznam.cz>:

If brackets [] are around cookie name,
next cookie names are not loaded.

try:
  import http.cookies as Cookie
except ImportError:
  import Cookie
c = Cookie.SimpleCookie()
c.load('id=12345; [object Object]=data; something=not loaded')
print(c)

Note:
It could cause big problems with session etc.
We found that Chrome/Edge starts to save and send this type of cookies for some (couple) users. The origin of that [object Object]=... cookies are probably some implementation of
https://cookiepedia.co.uk/cookies/euconsent
and errors somewhere in external javascripts or browsers?

Related issues:
https://bugs.python.org/issue41695
https://bugs.python.org/issue27674

The same problem occures in P3.7, P2.7, six.moves.http_cookies etc.

I know RFT says that cookie-name can't use brackets.
But you can set them to browser cookies.

RFC 6265:
set-cookie-header = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
 token             = <token, defined in [RFC2616], Section 2.2>

RFC 2616:
token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

----------
components: Library (Lib)
messages: 378041
nosy: xnovakj
priority: normal
severity: normal
status: open
title: http.cookies.SimpleCookie.parse error after [keys]
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct  5 12:06:07 2020
From: report at bugs.python.org (Stargirl Flowers)
Date: Mon, 05 Oct 2020 16:06:07 +0000
Subject: [New-bugs-announce] [issue41946] Add concrete examples to os.path
 documentation
Message-ID: <1601913967.48.0.506783023492.issue41946@roundup.psfhosted.org>


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

Presently the documentation for os.path (https://docs.python.org/3.8/library/os.path.html) doesn't contain any concrete examples of the input and outputs of the various path manipulation functions.

Contrast this to the Node.js documentation for similar functionality (https://nodejs.org/api/path.html)

We could add replesque examples such as:

>> os.path.abspath("example.py")
"/full/path/to/example.py"

...

>> os.path.basename("example.py")
"example"

& so on.

I believe it would be useful for us to have concrete examples here and I'm happy to contribute this. If anyone feels differently, let me know.

----------
assignee: docs at python
components: Documentation
messages: 378043
nosy: docs at python, theacodes
priority: normal
severity: normal
status: open
title: Add concrete examples to os.path documentation
type: enhancement

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

From report at bugs.python.org  Mon Oct  5 12:39:39 2020
From: report at bugs.python.org (Michael L. Boom)
Date: Mon, 05 Oct 2020 16:39:39 +0000
Subject: [New-bugs-announce] [issue41947] Tests When Building Python
Message-ID: <1601915979.99.0.0870574640961.issue41947@roundup.psfhosted.org>


New submission from Michael L. Boom <mikeboom at mikeboom.com>:

When building Python it runs 416 tests in sequence.  It would be a "lot" faster if these were run in parallel.

----------
components: Installation
messages: 378062
nosy: boom0192
priority: normal
severity: normal
status: open
title: Tests When Building Python
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct  5 16:36:17 2020
From: report at bugs.python.org (Abhi R)
Date: Mon, 05 Oct 2020 20:36:17 +0000
Subject: [New-bugs-announce] [issue41948] Runtime error while trying to use
 Python3.9 with virtualenv
Message-ID: <1601930177.87.0.41815594823.issue41948@roundup.psfhosted.org>


New submission from Abhi R <abhicantdraw at gmail.com>:

I tried to create a new virtual environment using virtualenv and the newly released Python3.9 version and I got a runtime error saying " failed to find interpreter for Builtin discover of python_spec='python3.9'".

----------
components: Interpreter Core
files: Untitled picture.png
messages: 378074
nosy: abhicantdraw
priority: normal
severity: normal
status: open
title: Runtime error while trying to use Python3.9 with virtualenv
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49496/Untitled picture.png

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

From report at bugs.python.org  Mon Oct  5 20:46:50 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 06 Oct 2020 00:46:50 +0000
Subject: [New-bugs-announce] [issue41949] Redefinition of HMAC functions
 prevents static linking
Message-ID: <1601945210.71.0.233142859875.issue41949@roundup.psfhosted.org>


New submission from Gregory Szorc <gregory.szorc at gmail.com>:

Commit 54f2898fe7e4ca1f239e96284af3cc5b34d2ae02 (bpo-40645) introduced the functions HMAC_CTX_new, HMAC_CTX_free, and HMAC_CTX_get_md.

These functions share the same names as HMAC functions provided by OpenSSL/LibreSSL. If you attempt to statically link the _hashlib extension as a builtin extension module that is also statically linked against a libcrytpo that provides these functions, the linker may complain about duplicate symbols:

cpython-3.9> /tools/host/bin/ld: /tools/deps/lib/libcrypto.a(libcrypto_la-hmac.o): in function `HMAC_CTX_free':
cpython-3.9> hmac.c:(.text+0x7d0): multiple definition of `HMAC_CTX_free';
cpython-3.9> Modules/_hashopenssl.o:/build/Python-3.9.0/./Modules/_hashopenssl.c:54: first defined here
cpython-3.9> /tools/host/bin/ld: /tools/deps/lib/libcrypto.a(libcrypto_la-hmac.o): in function `HMAC_CTX_get_md':
cpython-3.9> hmac.c:(.text+0xa20): multiple definition of `HMAC_CTX_get_md'; Modules/_hashopenssl.o:/build/Python-3.9.0/./Modules/_hashopenssl.c:                 63: first defined here
cpython-3.9> /tools/host/bin/ld: /tools/deps/lib/libcrypto.a(libcrypto_la-hmac.o): in function `HMAC_CTX_new':
cpython-3.9> hmac.c:(.text+0x780): multiple definition of `HMAC_CTX_new'; Modules/_hashopenssl.o:/build/Python-3.9.0/./Modules/_hashopenssl.c:42:                  first defined here
cpython-3.9> clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
cpython-3.9> ln: failed to access 'libpython3.9.so.1.0': No such file or directory
cpython-3.9> make: *** [libpython3.9.so] Error 1
cpython-3.9> Makefile:656: recipe for target 'libpython3.9.so' failed

This log from a build attempting to statically link against LibreSSL 3.1.4. The issue does not reproduce against OpenSSL 1.1.1h for some reason.

While statically linking _hashlib as a built-in extension module and statically linking libcrypto isn't in the default configuration, I believe this use case should be supported.

Perhaps these 3 functions should be renamed to not conflict with symbols provided by libcrypto?

----------
components: Extension Modules
messages: 378080
nosy: indygreg
priority: normal
severity: normal
status: open
title: Redefinition of HMAC functions prevents static linking
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  5 22:42:18 2020
From: report at bugs.python.org (Weiliang Li)
Date: Tue, 06 Oct 2020 02:42:18 +0000
Subject: [New-bugs-announce] [issue41950] Typo in Python 3.9 what's new page
Message-ID: <1601952138.4.0.0931015825602.issue41950@roundup.psfhosted.org>


New submission from Weiliang Li <to.be.impressive at gmail.com>:

CONTAINS_OP for ?in? and ?is not? tests

should be 

CONTAINS_OP for ?in? and ?not in? tests

Ref:
https://bugs.python.org/issue39156

----------
assignee: docs at python
components: Documentation
messages: 378085
nosy: docs at python, kigawas
priority: normal
severity: normal
status: open
title: Typo in Python 3.9 what's new page
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  5 22:51:39 2020
From: report at bugs.python.org (XIAO AN ZHENG)
Date: Tue, 06 Oct 2020 02:51:39 +0000
Subject: [New-bugs-announce] [issue41951] python-3.6.8.exe /uninstall /quiet
 fails woth Exit code: 0x643
Message-ID: <1601952699.58.0.0444624447975.issue41951@roundup.psfhosted.org>


New submission from XIAO AN ZHENG <xiaoanzhengca at yahoo.com>:

The issue is caused by uninstalling Python 3.8.2 which wrongly detected?core_JustForMe even API only installed Python for All users :

[1E18:1B64][2020-09-30T11:16:11]i101: Detected package: core_AllUsers, state: Present, cached: Complete
[1E18:1B64][2020-09-30T11:16:11]i101: Detected package: core_AllUsers_pdb, state: Absent, cached: None
[1E18:1B64][2020-09-30T11:16:11]i101: Detected package: core_AllUsers_d, state: Absent, cached: None
[1E18:1B64][2020-09-30T11:16:11]i101: Detected package: core_JustForMe, state: Present, cached: None

Here is the normal log:

[113C:02BC][2020-10-05T12:06:55]i101: Detected package: core_AllUsers, state: Present, cached: Complete
[113C:02BC][2020-10-05T12:06:55]i101: Detected package: core_AllUsers_pdb, state: Absent, cached: None
[113C:02BC][2020-10-05T12:06:55]i101: Detected package: core_AllUsers_d, state: Absent, cached: None
[113C:02BC][2020-10-05T12:06:55]i101: Detected package: core_JustForMe, state: Absent, cached: None

----------
components: Installation
messages: 378086
nosy: szheng
priority: normal
severity: normal
status: open
title: python-3.6.8.exe /uninstall /quiet fails woth Exit code: 0x643
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct  5 23:01:39 2020
From: report at bugs.python.org (Steven Yan)
Date: Tue, 06 Oct 2020 03:01:39 +0000
Subject: [New-bugs-announce] [issue41952] Extra Space Between "Oct" and "5"
Message-ID: <1601953299.33.0.696069011222.issue41952@roundup.psfhosted.org>


Change by Steven Yan <Steven_Bot_Yan at 126.com>:


----------
assignee: terry.reedy
components: IDLE
nosy: sy, terry.reedy
priority: normal
severity: normal
status: open
title: Extra Space Between "Oct" and "5"
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  6 01:12:45 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 06 Oct 2020 05:12:45 +0000
Subject: [New-bugs-announce] [issue41953] Confusing error message of 50,*2
Message-ID: <1601961165.99.0.783247818914.issue41953@roundup.psfhosted.org>


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

>>> (50,) * 2
(50, 50)
>>> 50, * 2
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: 'int' object is not iterable

This message is confusing. It isn't clear that 50.__iter__ is called. tuple(50)*2 seems to happen, which isn't expected (at least to regular users). Not like "50 * 2," that relates to parsing.

----------
components: Interpreter Core
messages: 378090
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Confusing error message of 50,*2
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  6 03:12:22 2020
From: report at bugs.python.org (Stanislav Levin)
Date: Tue, 06 Oct 2020 07:12:22 +0000
Subject: [New-bugs-announce] [issue41954] [mock] Recursion on mocking
 inspect.isfunction
Message-ID: <1601968342.61.0.658071347558.issue41954@roundup.psfhosted.org>


New submission from Stanislav Levin <slev at altlinux.org>:

With Python 3.8 the mocking of `inspect.isfunction` results in recursion.

Please, consider a code snippet:

```python
from unittest import TestCase
from unittest.mock import patch

import inspect

class TestClass(TestCase):
    def setUp(self):
        patcher = patch('inspect.isfunction')
        self.addCleanup(patcher.stop)
        self.patched_func = patcher.start()

    def test_m(self):
        def f():
           pass

        inspect.isfunction(f)
```

Output:
```
ERROR: test_m (test.TestClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/test.py", line 16, in test_m
    inspect.isfunction(f)
  File "/usr/lib64/python3.8/unittest/mock.py", line 1081, in __call__
    return self._mock_call(*args, **kwargs)
  File "/usr/lib64/python3.8/unittest/mock.py", line 1085, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
  File "/usr/lib64/python3.8/unittest/mock.py", line 1157, in _execute_mock_call
    return self.return_value
  File "/usr/lib64/python3.8/unittest/mock.py", line 526, in __get_return_value
    ret = self._get_child_mock(
  File "/usr/lib64/python3.8/unittest/mock.py", line 1025, in _get_child_mock
    return klass(**kw)
  File "/usr/lib64/python3.8/unittest/mock.py", line 408, in __new__
    sig = inspect.signature(NonCallableMock.__init__)
  File "/usr/lib64/python3.8/inspect.py", line 3093, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/usr/lib64/python3.8/inspect.py", line 2842, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "/usr/lib64/python3.8/inspect.py", line 2289, in _signature_from_callable
    if isfunction(obj) or _signature_is_functionlike(obj):
  File "/usr/lib64/python3.8/unittest/mock.py", line 1081, in __call__
    return self._mock_call(*args, **kwargs)
  File "/usr/lib64/python3.8/unittest/mock.py", line 1085, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
  File "/usr/lib64/python3.8/unittest/mock.py", line 1157, in _execute_mock_call
    return self.return_value
  File "/usr/lib64/python3.8/unittest/mock.py", line 526, in __get_return_value
    ret = self._get_child_mock(
  File "/usr/lib64/python3.8/unittest/mock.py", line 1025, in _get_child_mock
    return klass(**kw)
...

    return _signature_from_callable(obj, sigcls=cls,
RecursionError: maximum recursion depth exceeded
```

breaking commit: https://github.com/python/cpython/commit/77b3b7701a34ecf6316469e05b79bb91de2addfa

The pre-77b3b7701a34ecf6316469e05b79bb91de2addfa state of `Lib/unittest/mock.py` works as expected.

----------
messages: 378094
nosy: stanislavlevin
priority: normal
severity: normal
status: open
title: [mock] Recursion on mocking inspect.isfunction
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct  6 04:30:28 2020
From: report at bugs.python.org (Gaming With Skytorrush)
Date: Tue, 06 Oct 2020 08:30:28 +0000
Subject: [New-bugs-announce] [issue41955] Python Modules
Message-ID: <1601973028.51.0.57170333188.issue41955@roundup.psfhosted.org>


New submission from Gaming With Skytorrush <clashwithchiefrpjyt at gmail.com>:

Modules such as Pillow, Psycopg2, Psycopg2-binary are not installing via pip stating this version doesn't support those

----------
messages: 378096
nosy: clashwithchiefrpjyt
priority: normal
severity: normal
status: open
title: Python Modules
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  6 05:02:38 2020
From: report at bugs.python.org (Dan)
Date: Tue, 06 Oct 2020 09:02:38 +0000
Subject: [New-bugs-announce] [issue41956] Regression in HTMLParser on
 malformed tags
Message-ID: <1601974958.88.0.650741746715.issue41956@roundup.psfhosted.org>


New submission from Dan <negativeiq at gmail.com>:

The attached HTML document (pulled from a Samsung printer web interface) contains the following invalid HTML tag:
<img style="vertical-align:bottom;" ,="" src="images/sws/icon_alert_warning_16.gif" title="Warning">
(invalid because of ,="")
In Python 3.x completely stops the HTML parser, preventing any further tags from being parsed. This does not happen in Python 2.x
See the attached Python script, which counts the number of "input" tags. When executed using Python 2.7, it correctly counts 4 such tags. When executed using Python 3.8 it only finds 1.

----------
components: Library (Lib)
files: testhtmlparse.zip
messages: 378101
nosy: dan
priority: normal
severity: normal
status: open
title: Regression in HTMLParser on malformed tags
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49497/testhtmlparse.zip

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

From report at bugs.python.org  Tue Oct  6 06:55:52 2020
From: report at bugs.python.org (Alex)
Date: Tue, 06 Oct 2020 10:55:52 +0000
Subject: [New-bugs-announce] [issue41957] IDLE does not Transform Tabs into
 Spaces in Interactive Mode
Message-ID: <1601981752.02.0.169108716796.issue41957@roundup.psfhosted.org>


New submission from Alex <2423067593 at qq.com>:

In Python I usually find the problem like this.
>>> for i in range(10):
	#some code
In edit mode, IDLE will automatically transform tabs into spaces.
But in interactive mode, IDLE won't do the same.
The same problem have been reported in some other forums as far as I know.
I don't know how the problem is caused. However, we shoule look at this problem carefully, until we solve it.

----------
assignee: terry.reedy
components: IDLE
messages: 378112
nosy: Alex-Python-Programmer, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE does not Transform Tabs into Spaces in Interactive Mode
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct  6 09:08:55 2020
From: report at bugs.python.org (Mario Idival)
Date: Tue, 06 Oct 2020 13:08:55 +0000
Subject: [New-bugs-announce] [issue41958] importlib has not util module
Message-ID: <1601989735.99.0.481225793113.issue41958@roundup.psfhosted.org>


New submission from Mario Idival <marioidival at gmail.com>:

After new version 3.9, the util module from importlib does not exists anymore

>>> import importlib
>>> importlib.util.find_spec('enum')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'importlib' has no attribute 'util'
>>>

----------
components: Library (Lib)
messages: 378121
nosy: marioidival
priority: normal
severity: normal
status: open
title: importlib has not util module
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  6 09:51:04 2020
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Tue, 06 Oct 2020 13:51:04 +0000
Subject: [New-bugs-announce] [issue41959] Doc/library/asyncio-policy.rst
 grammar error
Message-ID: <1601992264.68.0.320872676637.issue41959@roundup.psfhosted.org>


New submission from Ra?l Cumplido <raulcumplido at gmail.com>:

The Doc/library/asyncio-policy.rst file contains the following:
```
This implementation registers a :py:data:`SIGCHLD` signal handler on instantiation. That can break third-party code that installs a custom handler for `SIGCHLD`.  signal).
```
The latest . and ) are incorrect.

----------
assignee: docs at python
components: Documentation
messages: 378124
nosy: docs at python, raulcd
priority: normal
severity: normal
status: open
title: Doc/library/asyncio-policy.rst grammar error
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  6 16:39:01 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 06 Oct 2020 20:39:01 +0000
Subject: [New-bugs-announce] [issue41960] Add globalns and localns to the
 inspect.signature and inspect.Signature.from_callable
Message-ID: <1602016741.16.0.216443843373.issue41960@roundup.psfhosted.org>


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

To resolve annotations in local namespaces (and possibly in different contexts), inspect.signature can take globalns and localns parameters.

I'm not inclined to add these into the getfullargspec, but I'd appreciate any comments about whether it is a good idea or not!

----------
components: Library (Lib)
messages: 378137
nosy: BTaskaya, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: Add globalns and localns to the inspect.signature and inspect.Signature.from_callable
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct  6 19:32:04 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Oct 2020 23:32:04 +0000
Subject: [New-bugs-announce] [issue41961] Windows install failure "could not
 set file security"
Message-ID: <1602027124.24.0.555629849122.issue41961@roundup.psfhosted.org>


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

Original report: https://twitter.com/Steve_Casselman/status/1313564671652159488?s=20

A user received MSI error 1926 in a popup dialog, text reading:

> Could not set file security for file 'C:\Users\sc\AppData\Roaming\Microsoft\Installer\'. Error: 0. Verify that you have sufficient privileges to modify the security permissions for this file.

OS version: 18362.1082 (Windows 10 Home 1903)

----------
components: Windows
messages: 378141
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Windows install failure "could not set file security"
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  6 21:09:44 2020
From: report at bugs.python.org (Ben Darnell)
Date: Wed, 07 Oct 2020 01:09:44 +0000
Subject: [New-bugs-announce] [issue41962] Make threading._register_atexit
 public?
Message-ID: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>


New submission from Ben Darnell <ben.darnell at gmail.com>:

I'm dealing with a subtle deadlock involving concurrent.futures.ThreadPoolExecutor, and my solution that worked in Python 3.8 broke with 3.9. I'm running some long-running (possibly infinite) tasks in the thread pool, and I cancel them in an `atexit` callback so that everything can shut down cleanly (before ThreadPoolExecutor joins all worker threads in its own `atexit` hook).

Python 3.9 broke this due to https://bugs.python.org/issue39812. That change introduced a new atexit-like mechanism to the threading module and uses it where Python 3.8 used regular atexit. This means that ThreadPoolExecutor's atexit runs before mine, and since I never get a chance to cancel my tasks, it deadlocks.

One way I can solve this is to move my own atexit function to `threading._register_atexit`, so my strawman proposal here is to make that function public and documented. 

On the other hand, even without the change in Python 3.9, my use of `atexit` smells like an abuse of implementation details in ThreadPoolExecutor (getting the atexit callbacks called in the right order was tricky when the concurrent.futures module started using lazy loading in Python 3.7). So I would welcome other suggestions about how to handle long-running but cancelable operations in a ThreadPoolExecutor at shutdown. 

One clean solution is to do the cancellation at the end of the main module instead of in an atexit hook. However, I'm doing this at a library so I don't have any way but atexit to ensure that this happens. Another option is to forego ThreadPoolExecutor entirely and manage the threads myself. 

My code in question is in a not-yet-released branch of Tornado: https://github.com/tornadoweb/tornado/blob/5913aa43ecfdaa76876fc57867062227b907b1dd/tornado/platform/asyncio.py#L57-L73

With the master branch of Tornado, Python 3.9, and Windows, `python -c "from tornado.httpclient import HTTPClient; c = HTTPClient()` reliably deadlocks at interpreter shutdown.

----------
messages: 378144
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: Make threading._register_atexit public?
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  7 03:21:09 2020
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Wed, 07 Oct 2020 07:21:09 +0000
Subject: [New-bugs-announce] [issue41963] ConfigParser: stripping of
 comments should be documented
Message-ID: <1602055269.91.0.0897084304522.issue41963@roundup.psfhosted.org>


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

While working on `tox-ini-fmt`, a formatter for - you guessed it - `tox.ini` files, I noticed ConfigParser strips comments when reading a config file.

( https://github.com/tox-dev/tox-ini-fmt/issues/34 )

While reasonable, this behaviour is surprising, as it is neither documented at https://docs.python.org/3/library/configparser.html nor in the docstrings (read and _read) which I read at first.

The stripping of comments is only documented with inline comments

https://github.com/jugmac00/cpython/blob/610a60c601fb4380eee30e15be1cd4dcbdaeec4c/Lib/configparser.py#L1019

and

https://github.com/jugmac00/cpython/blob/610a60c601fb4380eee30e15be1cd4dcbdaeec4c/Lib/configparser.py#L1031

Once I found these comments, I was surprised once again, as in my code the inline comments were not stripped. After some more pdb-ing and reading the source of ConfigParser, I noticed that - while comments have a default value, inline comments do not - and that is why when you read a config file, some comments get removed and others not.

I'd like to work on a pull request to document this behaviour, both in the official documentation and in the docstrings of the read and the _read methods.

----------
messages: 378146
nosy: jugmac00
priority: normal
severity: normal
status: open
title: ConfigParser: stripping of comments should be documented

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

From report at bugs.python.org  Wed Oct  7 03:34:46 2020
From: report at bugs.python.org (Snidhi Sofpro)
Date: Wed, 07 Oct 2020 07:34:46 +0000
Subject: [New-bugs-announce] [issue41964] difflib SequenceMatcher
 get_matching_blocks returns non-matching blocks in some cases
Message-ID: <1602056086.63.0.741821149494.issue41964@roundup.psfhosted.org>


New submission from Snidhi Sofpro <Snidhi.Sofpro at gmail.com>:

---------- Demo case with unexpected results starting from matching block 3 (result of code that follows):

sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0) 

Matches between:
<a id="nhix_Rgstr" href="http://local:56067/register/200930162135700">
<a id="nhix_Rgstr" href="http://local:53813/register/20100517282450281">

Match(a=0, b=0, size=39)
same-> <a id="nhix_Rgstr" href="http://local:5
same=> <a id="nhix_Rgstr" href="http://local:5 

Match(a=43, b=43, size=12)
same-> /register/20
same=> /register/20 

Match(a=59, b=55, size=1)
same-> 1
same=> 0 

Match(a=66, b=56, size=2)
same-> 00
same=> 93 

Match(a=68, b=70, size=2)
same-> ">
same=>  


# ---------- code that results in the above:

def get_mblk(dpiy_Frst, dpiy_Scnd):
    import difflib;
    sqmn_o = difflib.SequenceMatcher(None, dpiy_Frst, dpiy_Scnd);
    mblk_ls = [ block for block in sqmn_o.get_matching_blocks()];
    for mblk in mblk_ls[:-1]: #exclude the last dummy block
        print(mblk);
        mtch_a = dpiy_Frst[mblk.a : mblk.a + mblk.size];
        mtch_b = dpiy_Frst[mblk.b : mblk.b + mblk.size];
        print('same->', mtch_a);
        print('same=>', mtch_b, '\n');
    #endfor
#endef get_mblk

# --- main --

s1='<a id="nhix_Rgstr" href="http://local:56067/register/200930162135700">'
s2='<a id="nhix_Rgstr" href="http://local:53813/register/20100517282450281">'

import sys; print(sys.version_info, '\n');
print("Matches between:"); print(s1); print(s2); print('\n');
get_mblk(s1, s2);

----------
messages: 378149
nosy: Snidhi
priority: normal
severity: normal
status: open
title: difflib SequenceMatcher get_matching_blocks returns non-matching blocks in some cases
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct  7 04:39:18 2020
From: report at bugs.python.org (Alexander Todorov)
Date: Wed, 07 Oct 2020 08:39:18 +0000
Subject: [New-bugs-announce] [issue41965] distutils.spawn.find_executable()
 fails to find .py files on Windows
Message-ID: <1602059958.37.0.118353319302.issue41965@roundup.psfhosted.org>


New submission from Alexander Todorov <atodorov at otb.bg>:

As part of installing python-bugzilla via pip it searches for `rst2man` or `rst2man.py`, see:
https://github.com/python-bugzilla/python-bugzilla/blob/master/setup.py#L81

on Windows venvs there is venv\Scripts\rst2man.py (no .exe or without suffix) and when you call find_executable('rst2man.py') if doesn't find it.


The trouble is in this code snippet:

```
    _, ext = os.path.splitext(executable)
    if (sys.platform == 'win32') and (ext != '.exe'):
        executable = executable + '.exe'
```

`ext` here is `.py` and the if condition executes its body so the executable to search for becomes `rst2man.py.exe` which doesn't exist.

The extension check has been like that for more than 20 years:
https://github.com/python/cpython/commit/69628b0ad10f89a65902f5b911d1040ed9ae1ca2

but IMO it should be 

```
    if (sys.platform == 'win32') and (ext == ''):
        executable = executable + '.exe'
```

i.e. add `.exe` only if the file we're looking for doesn't already have an extension.


Let me know what you think? I can submit a PR for this.


Related issues:

- https://bugs.python.org/issue2200

- https://bugs.python.org/issue39260

----------
components: Distutils
messages: 378150
nosy: Alexander.Todorov, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.spawn.find_executable() fails to find .py files on Windows
type: behavior

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

From report at bugs.python.org  Wed Oct  7 06:08:31 2020
From: report at bugs.python.org (Dean)
Date: Wed, 07 Oct 2020 10:08:31 +0000
Subject: [New-bugs-announce] [issue41966] datetime.time issue with pickling
 in PyPy
Message-ID: <1602065311.95.0.279586156365.issue41966@roundup.psfhosted.org>


New submission from Dean <scaram at gmail.com>:

I've run into an issue pickling a datetime.time subclass in PyPy3. I believe it arises because PyPy uses the pure Python implementation of time and time.__reduce_ex__() returns (time, ...) on this line (https://github.com/python/cpython/blob/044a1048ca93d466965afc027b91a5a9eb9ce23c/Lib/datetime.py#L1551) rather than (self.__class__, ...) as it does for datetime.datetime (and in datetime.date.__reduce__()). So when pickle creates the dump it uses the time class rather than my subclass.

----------
components: Library (Lib)
messages: 378155
nosy: belopolsky, ddddaaaa, p-ganssle
priority: normal
severity: normal
status: open
title: datetime.time issue with pickling in PyPy
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  7 08:13:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 07 Oct 2020 12:13:41 +0000
Subject: [New-bugs-announce] [issue41967] Handle annotations in the parser
 to avoid the need for roundtrip
Message-ID: <1602072821.53.0.327570129065.issue41967@roundup.psfhosted.org>


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

For Python 3.10 now that annotations are always returned as strings, we can drop all the unparse logic by obtaining the string in the parser directly (after checking that the annotation is a valid expression).

----------
messages: 378158
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Handle annotations in the parser to avoid the need for roundtrip

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

From report at bugs.python.org  Wed Oct  7 09:54:09 2020
From: report at bugs.python.org (Velson Horie)
Date: Wed, 07 Oct 2020 13:54:09 +0000
Subject: [New-bugs-announce] [issue41968] 3.9 IDLE documentation.
Message-ID: <1602078849.36.0.609804596157.issue41968@roundup.psfhosted.org>


New submission from Velson Horie <c.v.horie at gmail.com>:

https://docs.python.org/3/library/idle.html
I am trying to sort out why a new installation of 3.9 onto Win10 64bit fails to associate a .py file type with IDLE. {hint - there is no idle.exe. installed - Why?}. 2.7, 3.6 and 3.8 worked fine.
The documentation gives no indication of the source format of "IDLE", where it might be found, what it calls etc - only how it is used.
Some indication/link to the underlying software structure should be included in the documentation.
PS thank you for all the other work involved.

----------
assignee: docs at python
components: Documentation
messages: 378161
nosy: c.v.horie, docs at python
priority: normal
severity: normal
status: open
title: 3.9 IDLE documentation.
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  7 13:02:37 2020
From: report at bugs.python.org (Athanasius)
Date: Wed, 07 Oct 2020 17:02:37 +0000
Subject: [New-bugs-announce] [issue41969] ttk.RadioButtons mis-sized under
 Windows 10 UI Scaling, with dpiAware set true
Message-ID: <1602090157.47.0.836989772149.issue41969@roundup.psfhosted.org>


New submission from Athanasius <github at miggy.org>:

Having recently looked into UI Scaling for an application I help develop I became aware with an issue involving tkinter.ttk.RadioButton and Windows UI Scaling.

When you have some UI Scaling set along with dpiAware set true you might find that radio buttons are mis-rendered. The usual manifestation of this is that the last button will be properly sized initially, with the others being undersized. If you even only mouse-over the 'correct' radio button it will then become undersized as well.

For more detail see: https://github.com/Athanasius/tk-radio-buttons

NB: This *has* been fixed upstream in the Tcl/Tk source, but I see they've not made a new release since 8.6.10 in November 2019.  Thus this issue is more in the way of a heads up about a bug others might encounter, and will have to wait for newer Tcl/Tk in some version of Python for it to be fixed.

See https://core.tcl-lang.org/tk/info/3c6660b6f0bed337 for the issue and fix.

----------
components: Tkinter
messages: 378171
nosy: Athanasius
priority: normal
severity: normal
status: open
title: ttk.RadioButtons mis-sized under Windows 10 UI Scaling, with dpiAware set true
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  7 19:05:57 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 07 Oct 2020 23:05:57 +0000
Subject: [New-bugs-announce] [issue41970] test_lib2to3 fails since Python 3.9
Message-ID: <1602111957.98.0.0630069409673.issue41970@roundup.psfhosted.org>


New submission from Felix Yan <felixonmars at archlinux.org>:

I am packaging Python for Arch and the tests suite of Python 3.8.6 pass here without this:

```
0:09:06 load avg: 0.87 [205/424] test_lib2to3                                                                                                                                                                                                                                                                         
test test_lib2to3 crashed -- Traceback (most recent call last):                                                                                                                                                                                                                                                       
  File "/build/python/src/Python-3.9.0/Lib/test/libregrtest/runtest.py", line 270, in _runtest_inner                                                                                                                                                                                                                  
    refleak = _runtest_inner2(ns, test_name)                                                                                                                                                                                                                                                                          
  File "/build/python/src/Python-3.9.0/Lib/test/libregrtest/runtest.py", line 221, in _runtest_inner2                                                                                                                                                                                                                 
    the_module = importlib.import_module(abstest)                                                                                                                                                                                                                                                                     
  File "/build/python/src/Python-3.9.0/Lib/importlib/__init__.py", line 127, in import_module                                                                                                                                                                                                                         
    return _bootstrap._gcd_import(name[level:], package, level)                                                                                                                                                                                                                                                       
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import                                                                                                                                                                                                                                                     
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load                                                                                                                                                                                                                                                  
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked                                                                                                                                                                                                                                          
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked                                                                                                                                                                                                                                                   
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module                                                                                                                                                                                                                                             
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed                                                                                                                                                                                                                                        
  File "/build/python/src/Python-3.9.0/Lib/test/test_lib2to3.py", line 5, in <module>                                                                                                                                                                                                                                 
    from lib2to3.tests import load_tests                                                                                                                                                                                                                                                                              
  File "/build/python/src/Python-3.9.0/Lib/contextlib.py", line 124, in __exit__                                                                                                                                                                                                                                      
    next(self.gen)                                                                                                                                                                                                                                                                                                    
  File "/build/python/src/Python-3.9.0/Lib/test/support/__init__.py", line 1171, in _filterwarnings                                                                                                                                                                                                                   
    raise AssertionError("filter (%r, %s) did not catch any warning" %                                                                                                                                                                                                                                                
AssertionError: filter ('', PendingDeprecationWarning) did not catch any warning                                                                                                                                                                                                                                      
                                                                                                                                                                                                                                                                                                                      
0:09:06 load avg: 0.87 [206/424/1] test_linecache -- test_lib2to3 failed    
```

----------
components: Tests
messages: 378190
nosy: felixonmars
priority: normal
severity: normal
status: open
title: test_lib2to3 fails since Python 3.9
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  7 19:07:56 2020
From: report at bugs.python.org (Felix Yan)
Date: Wed, 07 Oct 2020 23:07:56 +0000
Subject: [New-bugs-announce] [issue41971] multiple tests in test_tools fail
 since Python 3.9
Message-ID: <1602112076.31.0.668731548655.issue41971@roundup.psfhosted.org>


New submission from Felix Yan <felixonmars at archlinux.org>:

I am packaging Python for Arch and the test suite of Python 3.8.6 passes here without these:

======================================================================
FAIL: test_multiple_roots (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 118, in test_multiple_roots
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_w[26 chars]tion walk at 0x7ff2eb562f70>)), ('_walk', ('eg[42 chars]0>))] != [('_w[26 chars]tion _walk_tree at 0x7ff2e5babdc0>)), ('_walk'[54 chars]0>))]

First differing element 0:
('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>)),
?                                                     ^^^^^

+ [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>)),
?                                     +    +++++           + ^^^^

-  ('_walk', ('eggs', '.c', <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+  ('_walk', ('eggs', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_multiple_suffixes (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 189, in test_multiple_suffixes
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+ [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_no_suffix (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests) [None]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 209, in test_no_suffix
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+ [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_no_suffix (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests) []
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 209, in test_no_suffix
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', '', <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', '', <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', '', <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', '', <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', '', <function walk at 0x7ff2eb562f70>))]
?                                                   ^^^^^

+ [('_walk', ('spam', '', <function _walk_tree at 0x7ff2e5babdc0>))]
?                                   +    +++++           + ^^^^


======================================================================
FAIL: test_no_suffix (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests) [()]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 209, in test_no_suffix
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', (), <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', (), <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', (), <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', (), <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', (), <function walk at 0x7ff2eb562f70>))]
?                                                   ^^^^^

+ [('_walk', ('spam', (), <function _walk_tree at 0x7ff2e5babdc0>))]
?                                   +    +++++           + ^^^^


======================================================================
FAIL: test_one_root (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 99, in test_one_root
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+ [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_one_suffix (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 167, in test_one_suffix
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+ [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_relparent (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 228, in test_relparent
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_w[33 chars]tion walk at 0x7ff2eb562f70>)), ('_walk', ('/x[49 chars]0>))] != [('_w[33 chars]tion _walk_tree at 0x7ff2e5babdc0>)), ('_walk'[61 chars]0>))]

First differing element 0:
('_walk', ('/x/y/z/spam', '.c', <function walk at 0x7ff2eb562f70>))
('_walk', ('/x/y/z/spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('/x/y/z/spam', '.c', <function walk at 0x7ff2eb562f70>)),
?                                                            ^^^^^

+ [('_walk', ('/x/y/z/spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>)),
?                                            +    +++++           + ^^^^

-  ('_walk', ('/x/y/z/eggs', '.c', <function walk at 0x7ff2eb562f70>))]
?                                                            ^^^^^

+  ('_walk', ('/x/y/z/eggs', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]
?                                            +    +++++           + ^^^^


test test_tools failed
======================================================================
FAIL: test_single_root (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 82, in test_single_root
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+ [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_single_suffix (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 146, in test_single_suffix
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))] != [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]

First differing element 0:
('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', '.c', <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+ [('_walk', ('spam', '.c', <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


======================================================================
FAIL: test_typical (test.test_tools.test_c_analyzer.test_common.test_files.IterFilesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python/src/Python-3.9.0/Lib/test/test_tools/test_c_analyzer/test_common/test_files.py", line 64, in test_typical
    self.assertEqual(self.calls, [
AssertionError: Lists differ: [('_w[26 chars]tion walk at 0x7ff2eb562f70>)), ('_walk', ('eg[42 chars]0>))] != [('_w[26 chars]tion _walk_tree at 0x7ff2e5babdc0>)), ('_walk'[54 chars]0>))]

First differing element 0:
('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>))
('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>))

- [('_walk', ('spam', None, <function walk at 0x7ff2eb562f70>)),
?                                                     ^^^^^

+ [('_walk', ('spam', None, <function _walk_tree at 0x7ff2e5babdc0>)),
?                                     +    +++++           + ^^^^

-  ('_walk', ('eggs', None, <function walk at 0x7ff2eb562f70>))]
?                                                     ^^^^^

+  ('_walk', ('eggs', None, <function _walk_tree at 0x7ff2e5babdc0>))]
?                                     +    +++++           + ^^^^


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

Ran 184 tests in 3.357s

FAILED (failures=11, skipped=2, expected failures=14)
0:25:39 load avg: 0.95 [362/424/3] test_trace -- test_tools failed

----------
components: Tests
messages: 378191
nosy: felixonmars
priority: normal
severity: normal
status: open
title: multiple tests in test_tools fail since Python 3.9
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  7 19:31:59 2020
From: report at bugs.python.org (Kevin Mills)
Date: Wed, 07 Oct 2020 23:31:59 +0000
Subject: [New-bugs-announce] [issue41972] bytes.find consistently hangs in a
 particular scenario
Message-ID: <1602113519.53.0.297229304628.issue41972@roundup.psfhosted.org>


New submission from Kevin Mills <kevin.mills226+bugs.python at gmail.com>:

Sorry for the vague title. I'm not sure how to succinctly describe this issue.

The following code:

```
with open("data.bin", "rb") as f:
    data = f.read()

base = 15403807 * b'\xff'
longer = base + b'\xff'

print(data.find(base))
print(data.find(longer))
```

Always hangs on the second call to find.

It might complete eventually, but I've left it running and never seen it do so. Because of the structure of data.bin, it should find the same position as the first call to find.

The first call to find completes and prints near instantly, which makes the pathological performance of the second (which is only searching for one b"\xff" more than the first) even more mystifying.

I attempted to upload the data.bin file I was working with as an attachment here, but it failed multiple times. I assume it's too large for an attachment; it's a 32MiB file consisting only of 00 bytes and FF bytes.

Since I couldn't attach it, I uploaded it to a gist. I hope that's okay.

https://gist.github.com/Zeturic/7d0480a94352968c1fe92aa62e8adeaf

I wasn't able to trigger the pathological runtime behavior with other sequences of bytes, which is why I uploaded it in the first place. For example, if it is randomly generated, it doesn't trigger it.

I've verified that this happens on multiple versions of CPython (as well as PyPy) and on multiple computers / operating systems.

----------
messages: 378197
nosy: Zeturic
priority: normal
severity: normal
status: open
title: bytes.find consistently hangs in a particular scenario
type: performance
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct  8 02:26:46 2020
From: report at bugs.python.org (Bernat Gabor)
Date: Thu, 08 Oct 2020 06:26:46 +0000
Subject: [New-bugs-announce] [issue41973] Docs: TypedDict is now of type
 function instead of class
Message-ID: <1602138406.98.0.272652370144.issue41973@roundup.psfhosted.org>


New submission from Bernat Gabor <gaborjbernat at gmail.com>:

? py -3.8 -c 'from typing import TypedDict; print(type(TypedDict))'
<class 'typing._TypedDictMeta'>

? py -3.9 -c 'from typing import TypedDict; print(type(TypedDict))'
<class 'function'>

Python 3.9 changed the type of the TypedDict but the documentation still says it's a class - see https://docs.python.org/3.9/library/typing.html#typing.TypedDict. I must also say I'm suprised you can inherit from a function, but we should update the documentation to reflect that the type of the element in question is no longer class.

----------
messages: 378212
nosy: gaborjbernat
priority: normal
severity: normal
status: open
title: Docs: TypedDict is now of type function instead of class
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Oct  8 02:55:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Oct 2020 06:55:25 +0000
Subject: [New-bugs-announce] [issue41974] Remove complex.__float__,
 complex.__floordiv__, etc
Message-ID: <1602140125.13.0.506221233573.issue41974@roundup.psfhosted.org>


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

The complex class has special methods which always raise a TypeError:

   __int__
   __float__
   __floordiv__
   __mod__
   __divmod__

After removing them the corresponding operations (converting to int and float, operators // and %, function divmod()) will still a TypeError.

Advantages of removing:

* Less code to maintain.
* More uniform error messages.
* Clearer output of help().
* Possibility to implement a type with __rfloordiv__, __rmod__ and __rdivmod__ which support complex numbers.

----------
components: Interpreter Core
messages: 378218
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Remove complex.__float__, complex.__floordiv__, etc
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  8 09:19:58 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 08 Oct 2020 13:19:58 +0000
Subject: [New-bugs-announce] [issue41975] Textwrap to conform to
 https://www.unicode.org/reports/tr14/tr14-45.html
Message-ID: <1602163198.82.0.518755458175.issue41975@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

Currently it looks like our `textwrap.fill` implementation does not conforms to the Unicode Line Breaking Algorithm from the unicode standard.

Should this be enhanced?

If so, as a sidenote, it could be nice to have the override parameter of  libunistring [1] to prohibit line breaking at specific places where the algorithm would normally break but where a human don't expect it to.

[1]: https://www.gnu.org/software/libunistring/manual/html_node/unilbrk_002eh.html

----------
components: Library (Lib)
messages: 378247
nosy: mdk
priority: normal
severity: normal
status: open
title: Textwrap to conform to https://www.unicode.org/reports/tr14/tr14-45.html

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

From report at bugs.python.org  Thu Oct  8 13:17:51 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 08 Oct 2020 17:17:51 +0000
Subject: [New-bugs-announce] [issue41976] ctypes.util.find_library fails
 with gcc 9
Message-ID: <1602177471.33.0.207499643707.issue41976@roundup.psfhosted.org>


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

Running ctypes.util.find_library with gcc-9, if ldconfig is not available, it falls back to check the output of gcc -Wl,-t -lc to locate the library and then runs objdump on the file it's found to parse out the SONAME. With the gcc-9 the output of that gcc command is slightly perturbed so that /lib64/libc.so is listed before /libc64/libc.so.6. The former is a linker script not and ELF file so objdump fails.

----------
assignee: pablogsal
components: ctypes
messages: 378258
nosy: pablogsal
priority: normal
severity: normal
status: open
title: ctypes.util.find_library fails with gcc 9
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct  8 13:49:07 2020
From: report at bugs.python.org (Maximilian Pichler)
Date: Thu, 08 Oct 2020 17:49:07 +0000
Subject: [New-bugs-announce] [issue41977] ctypes array inside structure
 requires explicit garbage collection
Message-ID: <1602179347.57.0.693191135909.issue41977@roundup.psfhosted.org>


New submission from Maximilian Pichler <maxim.pichler at gmail.com>:

If we initialize a `Structure` with two fields as...
```python
s = S()
s.x = (c_int * 10**8)()
s.y = s.x
```
...and then delete it with ```del s```, the memory allocated for the array is not freed until `gc.collect()` is called.

If instead we initalize `s` as...
```python
s = S()
a = (c_int * 10**8)()
s.x = a
s.y = a
del a
```
the memory is freed immediately, no need to garbage collect.

This behaviour seems inconsistent.

Also, if instead of `del s` we do...
```python
s.x = None
s.y = None
```
...memory usage remains high even after garbage collection.

Full code:
```python
import os, sys, gc
from ctypes import *

class S(Structure):
    _fields_ = [ ("x", POINTER(c_int)), ("y", POINTER(c_int)) ]

    def __del__(self):
        print("__del__ was called")

def dump_mem(): os.system(f"ps -o rss {os.getpid()}")

dump_mem() # ~ 6 MB

s = S()
s.x = (c_int * 10**8)()
s.y = s.x

dump_mem() # ~ 397 MB

del s # prints "__del__ was called" immediatly

dump_mem() # ~ 397 MB

gc.collect()

dump_mem() # ~ 6 MB
```

----------
components: ctypes
messages: 378262
nosy: maxim.pichler
priority: normal
severity: normal
status: open
title: ctypes array inside structure requires explicit garbage collection
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  9 01:10:30 2020
From: report at bugs.python.org (Thomas M. Alldread)
Date: Fri, 09 Oct 2020 05:10:30 +0000
Subject: [New-bugs-announce] [issue41978] numpy,
 scipy packages failed to install via pip - Windows 10 Pro 64 bit
Message-ID: <1602220230.71.0.716274521226.issue41978@roundup.psfhosted.org>


New submission from Thomas M. Alldread <tma.7ta at gmail.com>:

Several attempts to install numpy/scipy packages failed. Pip reported pages of error information. Reverting back to version 3.8.5 resolved the issue using the exact same procedure.

----------
components: Extension Modules, Installation, Windows
messages: 378303
nosy: paul.moore, steve.dower, tim.golden, tma, zach.ware
priority: normal
severity: normal
status: open
title: numpy, scipy packages failed to install via pip - Windows 10 Pro 64 bit
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  9 02:56:54 2020
From: report at bugs.python.org (Joshua Oreman)
Date: Fri, 09 Oct 2020 06:56:54 +0000
Subject: [New-bugs-announce] [issue41979] PEG parser doesn't accept extended
 unpacking in with statement
Message-ID: <1602226614.34.0.867074819586.issue41979@roundup.psfhosted.org>


New submission from Joshua Oreman <oremanj at gmail.com>:

On Python 3.9.0 with the new PEG parser, the following statement produces a SyntaxError:

with contextlib.nullcontext(range(1, 5)) as (first, *rest, last):
    print(first, rest, last)

On 3.8.x, or 3.9.0 with -X oldparser, it succeeds and prints "1 [2, 3] 4" as expected.

As I understand it, the thing after 'as' is an assignment target and should accept anything that can go on the LHS of an equals sign.

----------
components: Interpreter Core
messages: 378305
nosy: Joshua Oreman
priority: normal
severity: normal
status: open
title: PEG parser doesn't accept extended unpacking in with statement
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  9 08:34:19 2020
From: report at bugs.python.org (Yannick Gingras)
Date: Fri, 09 Oct 2020 12:34:19 +0000
Subject: [New-bugs-announce] [issue41980] Argparse documentation is slightly
 misleading
Message-ID: <1602246859.95.0.133972345732.issue41980@roundup.psfhosted.org>


New submission from Yannick Gingras <ygingras at ygingras.net>:

In argparse.rst, while documenting ArgumentParser.add_subparsers, ``prog`` is described on line 1630 as:
  usage information that will be displayed with sub-command help,
  by default the name of the program and any positional arguments 
  before the subparser argument

This is confusing since ``prog`` is actually a very small prefix of the usage message.  Describing this parameter as "name of the program" or event "name of the program with sub-commands" would be more clear.

----------
components: Library (Lib)
messages: 378316
nosy: ygingras
priority: normal
severity: normal
status: open
title: Argparse documentation is slightly misleading
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  9 09:19:51 2020
From: report at bugs.python.org (Federico Tesser)
Date: Fri, 09 Oct 2020 13:19:51 +0000
Subject: [New-bugs-announce] [issue41981] Errors building python 3.9.0 from
 source
Message-ID: <1602249591.17.0.670337051124.issue41981@roundup.psfhosted.org>


New submission from Federico Tesser <federico.tesser at polito.it>:

Good afternoon.

I have some problems building python 3.9.0 from source.

Here's my configuration:

CC=/usr/local/gcc-10.2.0/bin/gcc CXX=/usr/local/gcc-10.2.0/bin/g++ CFLAGS="-I/usr/local/libuuid-1.0.3/include/ -I/usr/local/libuuid-1.0.3/include/uuid/ -I/usr/local/xz-utils-5.2.4/include/ -I/usr/local/bzip2-1.0.8/include/ -I/usr/local/gdbm-1.18.1/include/ -I/usr/local/libffi-3.3/include/ -I/usr/local/openssl-1.1.1d/openssl-1.1.1d/include/ -I/usr/local/ncurses-6.2/include/ncursestw/ -I/usr/local/readline-8.0/include/readline/ -I/usr/local/x11-7.7/libx11-1.5.0/include/ -I/usr/local/tk-8.7a3/include/ -I/usr/local/tcl-8.7a3/include/" CPPFLAGS="-I/usr/local/libuuid-1.0.3/include/ -I/usr/local/libuuid-1.0.3/include/uuid/ -I/usr/local/xz-utils-5.2.4/include/ -I/usr/local/bzip2-1.0.8/include/ -I/usr/local/gdbm-1.18.1/include/ -I/usr/local/libffi-3.3/include/ -I/usr/local/openssl-1.1.1d/openssl-1.1.1d/include/ -I/usr/local/ncurses-6.2/include/ncursestw/ -I/usr/local/readline-8.0/include/readline/ -I/usr/local/x11-7.7/libx11-1.5.0/include/ -I/usr/local/tk-8.7a3/include/ -I/usr/local/tcl-8.7a3/include/" LDFLAGS="-L/usr/local/libuuid-1.0.3/lib/ -L/usr/local/xz-utils-5.2.4/lib/ -L/usr/local/bzip2-1.0.8/lib/ -L/usr/local/gdbm-1.18.1/lib/ -L/usr/local/libffi-3.3/lib64/ -L/usr/local/openssl-1.1.1d/openssl-1.1.1d/lib/ -L/usr/local/ncurses-6.2/lib/ -L/usr/local/readline-8.0/lib/ -L/usr/local/x11-7.7/libx11-1.5.0/lib/ -L/usr/local/tk-8.7a3/lib/ -L/usr/local/tcl-8.7a3/lib/" PKG_CONFIG_PATH="/usr/local/libuuid-1.0.3/lib/pkgconfig/:/usr/local/xz-utils-5.2.4/lib/pkgconfig/:/usr/local/libffi-3.3/lib/pkgconfig/:/lib64/pkgconfig/:/usr/local/readline-8.0/lib/pkgconfig/:/usr/local/x11-7.7/libx11-1.5.0/lib/pkgconfig/:/usr/local/tk-8.7a3/lib/pkgconfig/:/usr/local/tcl-8.7a3/lib/pkgconfig/" ./configure --prefix=/usr/local/python-3.9.0/ --with-tcltk-includes="-I/usr/local/tcl-8.7a3/include/ -I/usr/local/tk-8.7a3/include/" --with-tcltk-libs="-L/usr/local/tcl-8.7a3/lib/ -L/usr/local/tk-8.7a3/lib/" --with-libs="-luuid -lX11 -ltcl8.7 -ltk8.7 -lpanelw -lbz2" --disable-ipv6 --enable-optimizations --with-lto

During the make process, I receive the following error:

Python/pytime.c: In function ?pymonotonic?:
Python/pytime.c:907:9: error: implicit declaration of function ?pytime_fromtimespec?; did you mean ?pytime_fromtimeval?? [-Werror=implicit-function-declaration]
  907 |     if (pytime_fromtimespec(tp, &ts, raise) < 0) {
      |         ^~~~~~~~~~~~~~~~~~~
      |         pytime_fromtimeval
cc1: some warnings being treated as errors

If in the Makefile I change the "-Werror=implicit-function-declaration"
as "-Wno-error=implicit-function-declaration", the building process continues, but then it get stuck at:

Python/strdup.c: In function ?strdup?:
Python/strdup.c:6:16: error: ?NULL? undeclared (first use in this function)
    6 |     if (str != NULL) {
      |                ^~~~
Python/strdup.c:1:1: note: ?NULL? is defined in header ?<stddef.h>?; did you forget to ?#include <stddef.h>??

If I add the "#include <stddef.h>" in file "Python/strdup.c:", then the process continues, until I receive the following error:

./Modules/getpath.c:1198:14: error: incompatible types when assigning to type ?PyStatus? from type ?int?

If I explicitly add in file "Include/internal/pycore_initconfig.h", just after line 25, the following 3 lines:

 .func = 0, \
 .err_msg = 0, \
 .exitcode = 0}

Addition wich does not help, because the building process stop itself again at the previous point.

Can you tell me where I am doing wrong?

Best regards,

Federico Tesser

----------
components: Installation
messages: 378317
nosy: ftesser
priority: normal
severity: normal
status: open
title: Errors building python 3.9.0 from source
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  9 09:43:54 2020
From: report at bugs.python.org (iljah)
Date: Fri, 09 Oct 2020 13:43:54 +0000
Subject: [New-bugs-announce] [issue41982] Wrong location flagged as syntax
 error
Message-ID: <1602251034.78.0.495592912184.issue41982@roundup.psfhosted.org>


New submission from iljah <ilja.honkonen at protonmail.ch>:

File:
#! /usr/bin/env python3
with \
  open('file1', 'w') as file1,
  open('file2', 'w') as file2:

  print('ok')

gives error:
  File "./test.py", line 3
    open('file1', 'w') as file1,
                         ^
SyntaxError: invalid syntax

but adding \ after file1 fixes it:
  open('file1', 'w') as file1, \


Location flagged by syntax error (between as and file1) is not correct.

----------
components: Interpreter Core
messages: 378321
nosy: iljah
priority: normal
severity: normal
status: open
title: Wrong location flagged as syntax error
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  9 10:59:09 2020
From: report at bugs.python.org (Darnel T.)
Date: Fri, 09 Oct 2020 14:59:09 +0000
Subject: [New-bugs-announce] [issue41983] Missing Documentation AF_PACKET
Message-ID: <1602255549.69.0.358914707678.issue41983@roundup.psfhosted.org>


New submission from Darnel T. <darnelgt33 at gmail.com>:

Python documentation said AF_PACKET exists, but when I looked at the python script it was missing on Mac and Windows. I'm currently on Windows.

----------
assignee: docs at python
components: Documentation
messages: 378331
nosy: TheNuGuy, docs at python
priority: normal
severity: normal
status: open
title: Missing Documentation AF_PACKET
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  9 15:17:48 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 09 Oct 2020 19:17:48 +0000
Subject: [New-bugs-announce] [issue41984] Empty __slots__ can create
 untracked reference cycles
Message-ID: <1602271068.86.0.423346630238.issue41984@roundup.psfhosted.org>


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

Currently, we don't track instances of certain heap types based on the assumption that "no members" == "no reference cycles".

Unfortunately, it's still possible to create untracked reference cycles with one's parents. The following program leaks memory:

while True:
? ? class C:
? ? ? ? __slots__ = ()
? ? C.i = C()
? ? del C

The fix is simple: track all instances of user-defined classes, no exceptions. I'm not sure we were actually getting any real wins from the old behavior anyways.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 378337
nosy: brandtbucher, pablogsal
priority: low
severity: normal
status: open
title: Empty __slots__ can create untracked reference cycles
type: resource usage
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct  9 15:32:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Oct 2020 19:32:31 +0000
Subject: [New-bugs-announce] [issue41985] Argument Clinic: add converter for
 file descriptor
Message-ID: <1602271951.8.0.643355348973.issue41985@roundup.psfhosted.org>


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

Local converters for file descriptors which uses PyObject_AsFileDescriptor() are defined and used in several files: Modules/fcntlmodule.c, Modules/posixmodule.c, Modules/selectmodule.c, Modules/termios.c.

The proposed PR replaces them all with a global private function _PyLong_FileDescriptor_Converter() and adds corresponding Argument Clinic converter "fildes".

In future it could be used in more places, allowing to pass a file with fileno() method to functions which accept file descriptor.

----------
components: Argument Clinic
messages: 378338
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: add converter for file descriptor
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct  9 15:48:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Oct 2020 19:48:03 +0000
Subject: [New-bugs-announce] [issue41986] Py_FileSystemDefaultEncodeErrors
 and Py_UTF8Mode are not available with limited API
Message-ID: <1602272883.67.0.0325810953138.issue41986@roundup.psfhosted.org>


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

Py_FileSystemDefaultEncodeErrors was added to limited API in 3.7 and Py_UTF8Mode -- in 3.7. But in 3.8 their declarations are not available if Py_LIMITED_API is defined because they were moved to different header file included only if Py_LIMITED_API is not defined.

----------
components: C API
messages: 378340
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Py_FileSystemDefaultEncodeErrors and Py_UTF8Mode are not available with limited API
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct  9 16:11:43 2020
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Fri, 09 Oct 2020 20:11:43 +0000
Subject: [New-bugs-announce] [issue41987] singledispatchmethod raises an
 error when relying on a forward declaration
Message-ID: <1602274303.54.0.362260014367.issue41987@roundup.psfhosted.org>


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

This example:


from __future__ import annotations
from functools import singledispatchmethod


class Comparable:
    @singledispatchmethod
    def compare(self, arg: object):
        raise NotImplementedError("what")

    @compare.register
    def _(self, arg: Comparable):
        return "somewhat similar"


print(Comparable().compare(Comparable()))


Produces this result:

  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/typing.py", line 518, in _evaluate
    eval(self.__forward_code__, globalns, localns),
  File "<string>", line 1, in <module>
NameError: name 'Comparable' is not defined

It seems like perhaps singledispatchmethod should defer its type evaluation to its first invocation?

----------
components: Library (Lib)
messages: 378346
nosy: glyph
priority: normal
severity: normal
stage: needs patch
status: open
title: singledispatchmethod raises an error when relying on a forward declaration
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  9 16:44:30 2020
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Fri, 09 Oct 2020 20:44:30 +0000
Subject: [New-bugs-announce] [issue41988] No hyphen in broken up word in
 documentation
Message-ID: <1602276270.7.0.489043595778.issue41988@roundup.psfhosted.org>


New submission from Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com>:

In the decimal module documentation:

https://docs.python.org/3/library/decimal.html

Arithmetic is broken up for me as "Arith\nmetic", not the missing hyphen, unless I am mistaken it should be "Arith-\nmetic". Is this a Sphinx issue? Is this a browser issue? Is this an issue on our end? Later it does break "Applications" correctly.

See attached screenshot.

----------
assignee: docs at python
components: Documentation
files: Screenshot 2020-10-09 at 21.43.50.png
messages: 378351
nosy: cryvate, docs at python
priority: normal
severity: normal
status: open
title: No hyphen in broken up word in documentation
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49504/Screenshot 2020-10-09 at 21.43.50.png

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

From report at bugs.python.org  Fri Oct  9 21:08:29 2020
From: report at bugs.python.org (Waylan Limberg)
Date: Sat, 10 Oct 2020 01:08:29 +0000
Subject: [New-bugs-announce] [issue41989] htmlparser unclosed script tag
 causes data loss
Message-ID: <1602292109.75.0.598084394689.issue41989@roundup.psfhosted.org>


New submission from Waylan Limberg <waylan.limberg at icloud.com>:

When the `close` method of the HtmlParser is called, any cached text data is generally flushed and passed to a `data` event; except when in `data_mode`. Specifically, if an unclosed `script` or `style` tag has been encountered, a call to `close` does not flush the data.

A simple test which demonstrates the issue is attached.

I see that in Lib/html/parser.py#L244-L249 there are two nested if statements which both check for `not self.cdata_elem`. Obviously, if we got past the first one, that situation will never exist for the nested one. Somehow this block of code needs a branch for when `self.cdata_elem` is True.

I should note that the input is invalid HTML. However, the existing behavior results in data loss. Within any other unclosed tag (other than `script` or `style`) any data is still flushed and passed to a `data` event. I would expect the same behavior here. Although, the data escaping behavior should perhaps be applied as it is with data within properly closed tags.

----------
components: Library (Lib)
files: test_html.py
messages: 378359
nosy: waylan
priority: normal
severity: normal
status: open
title: htmlparser unclosed script tag causes data loss
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49505/test_html.py

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

From report at bugs.python.org  Sat Oct 10 03:24:45 2020
From: report at bugs.python.org (Bernd Wechner)
Date: Sat, 10 Oct 2020 07:24:45 +0000
Subject: [New-bugs-announce] [issue41990] venv module clashes with pip
 --user ... improve coordination.
Message-ID: <1602314685.15.0.298308328317.issue41990@roundup.psfhosted.org>


New submission from Bernd Wechner <bernd.wechner at gmail.com>:

When developing Python software it is highly discouraged to install python modules globally (risking adverse impacts upon the underlying OS where if has Python dependencies).

Project by project this typically done with venvs (and the venv module)

User by user it is typically done with the --user option.

In fact to make impacting system libraries less likely a pip.conf file can be written that contains:

[install]
user = true

I suspect this is an increasingly common practice which means pip installs are on a local user profile not into system dirs. 

Alas when in a venv now, pip bombs with a detected conflict:

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

This was explored with pip here:

https://github.com/pypa/pip/issues/8977

It turns out that pip can be made to function by overriding this setting in the venv. That is depositing a pip.conf in the vend dir that contains:

[install]
user = true

and all is good once more. In the activated venv pip now works again. 

This is at its core a coordination issue then between the venv module and pip and the point to fix it seems most likely to be in the venv module which, knowing that this conflict can exist can as a safety precaution simply always, or optionally, write a pip.conf into newly created venvs that disables the user options. Given pip won't work in a venv if that option is enabled and we know that up front.

Why fix it in the venv module? Because discovering the cause of this conflict was time consuming and disorienting, poor UX by any definition and it should ideally not arise or if it must have an easily discovered fix. 

This is a request to prevent it arising altogether in newly created venvs.

----------
components: Library (Lib)
messages: 378368
nosy: bernd.wechner
priority: normal
severity: normal
status: open
title: venv module clashes with pip --user ... improve coordination.
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 10 03:47:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2020 07:47:11 +0000
Subject: [New-bugs-announce] [issue41991] Remove _PyObject_HasAttrId
Message-ID: <1602316031.88.0.412712857392.issue41991@roundup.psfhosted.org>


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

_PyObject_HasAttrId() can return -1, 0 or 1. It returns -1 when cannot create a string (most likely due to MemoryError or UnicodeDecodeError), but returns 0 and silences all exceptions raised when look up the attribute (including MemoryError, KeybordInterruptError and RecursionError). Silencing arbitrary exceptions is bad, and the interface of the function is inconsistent, so it is better to remove it and replace all 5 of its occurrences in 3 files with _PyObject_LookupAttrId(). It is private API, so we can do it without breaking user code.

----------
components: Interpreter Core
messages: 378370
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Remove _PyObject_HasAttrId
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 10 06:33:57 2020
From: report at bugs.python.org (Aruna Gopalan)
Date: Sat, 10 Oct 2020 10:33:57 +0000
Subject: [New-bugs-announce] [issue41992] Unable to install lxml using pip
 in Python 3.9
Message-ID: <1602326037.24.0.900103901321.issue41992@roundup.psfhosted.org>


New submission from Aruna Gopalan <a21678 at yahoo.com>:

Installed Python 3.9 from Python.org
Tried installing lxml package using the command
"pip install lxml"
It complains that it is unable to do so without libxml2 (which is not a python package). I do not have the same issue with 3.8.6.

----------
components: Library (Lib)
messages: 378377
nosy: agopalan
priority: normal
severity: normal
status: open
title: Unable to install lxml using pip in Python 3.9
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 10 06:51:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2020 10:51:27 +0000
Subject: [New-bugs-announce] [issue41993] Possible issues when remove not
 completely initialized module from sys.module
Message-ID: <1602327087.97.0.628811045218.issue41993@roundup.psfhosted.org>


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

There are several issues in remove_module() in Python/import.c.

1. PyMapping_HasKey() is used to determine if the module was in sys.modules before removing it. But it can return 0 not only when the key is absent in the mapping, but also when some exceptions was raised during checking (including MemoryError, KeybordInterraption and RecursionError). The corresponding exception will be silenced and the module will be left in sys.modules.

2. If PyMapping_DelItem() fails, a RuntimeError is raised. It is chained with the exception raised in PyMapping_DelItem(), but the original exception, raised before calling remove_module() will be lost.

3. There is a possible race condition between PyMapping_HasKey() and PyMapping_DelItem().

----------
components: Interpreter Core
messages: 378382
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible issues when remove not completely initialized module from sys.module
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 10 07:14:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2020 11:14:48 +0000
Subject: [New-bugs-announce] [issue41994] Refcount issues in import
Message-ID: <1602328488.44.0.393274794411.issue41994@roundup.psfhosted.org>


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

There is a reference leak in import_add_module(). PyDict_GetItemWithError() returns a borrowed reference, but PyObject_GetItem() return a non-borrowed reference. If sys.modules is not a dict, there is a reference leak. import_add_module() and several other function which return a borrowed reference should be made returning a non-borrowed reference, because there are no guaranties that general mapping keeps reference to value.

It is still not guarantee correctness of PyImport_AddModuleObject().

----------
components: Interpreter Core
messages: 378384
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refcount issues in import
type: resource usage
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Oct 10 07:49:40 2020
From: report at bugs.python.org (brightest star)
Date: Sat, 10 Oct 2020 11:49:40 +0000
Subject: [New-bugs-announce] [issue41995] five possible Null Pointer
 Dereference bugs.
Message-ID: <1602330580.94.0.791834118141.issue41995@roundup.psfhosted.org>


New submission from brightest star <brightest3379 at gmail.com>:

Hello everyone,

I have found five Null Pointer Dereference bugs in recent master branch.
Although it's impact could be slightly, i think it is better to fix it.

Bug 1:
In the file ; ./Modules/_tracemalloc.c:
static int
tracemalloc_copy_trace(_Py_hashtable_t *traces,
                       const void *key, const void *value,
                       void *user_data)
{
        _Py_hashtable_t *traces2 = (_Py_hashtable_t *)user_data;

        trace_t *trace = (trace_t *)value;

1201:    trace_t *trace2 = raw_malloc(sizeof(trace_t));
1202:    if (traces2 == NULL) {  <-----
            return -1;
        }
1205:   *trace2 = *trace;
        ...
        return 0;
}
At line 1201, we malloc a varible 'trace2' and then we should check whether the varible 'trace2' is NULL. But it checks 'traces2'(not 'trace2') in line 1202. The varible 'trace2' still could be NULL.I think it is a spelling mistake.

Bug 2 and 3:
In the file :Modules/_zoneinfo.c

static int
load_data(PyZoneInfo_ZoneInfo *self, PyObject *file_obj)
{
        ...
908:     self->trans_list_utc =
        PyMem_Malloc(self->num_transitions * sizeof(int64_t));
910:    trans_idx = PyMem_Malloc(self->num_transitions * sizeof(Py_ssize_t));
        ...
}
Line 908 alloc a memory to 'self->trans_list_utc' and line 910 alloc a memory to 'trans_idx'. But the paramters passed to PyMem_Malloc are not fixed,it means that we possible could control the size to malloc. If we pass a big size to PyMem_Malloc, it will return NULL.
So,we should add some checks for 'self->trans_list_utc' and 'trans_idx',such as 
    if (self->trans_list_utc == NULL) {
        goto error;
    }

Bug 4 and 5:
In the file :Modules/_zoneinfo.c

The problem same to bug 3 and 4.
line 991:    self->_ttinfos = PyMem_Malloc(self->num_ttinfos * sizeof(_ttinfo));
line 1005:   self->trans_ttinfos =
        PyMem_Calloc(self->num_transitions, sizeof(_ttinfo *));

We should add some checks below these lines.

----------
components: Extension Modules
messages: 378385
nosy: brightest3379
priority: normal
severity: normal
status: open
title: five possible Null Pointer Dereference bugs.
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 10 08:21:05 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sat, 10 Oct 2020 12:21:05 +0000
Subject: [New-bugs-announce] [issue41996] Should `make install` still
 install to /usr/bin/python3?
Message-ID: <1602332465.75.0.920875873231.issue41996@roundup.psfhosted.org>


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

Since Python 2 is now finally gone, should the Python executable not be installed to simply `/usr/bin/python` rather than `/usr/bin/python3` when running `make install`?

----------
components: Installation
messages: 378387
nosy: pxeger
priority: normal
severity: normal
status: open
title: Should `make install` still install to /usr/bin/python3?
type: enhancement

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

From report at bugs.python.org  Sat Oct 10 09:09:31 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sat, 10 Oct 2020 13:09:31 +0000
Subject: [New-bugs-announce] [issue41997] Docs Standard Library index page
 has incorrect version in title
Message-ID: <1602335371.9.0.177302242721.issue41997@roundup.psfhosted.org>


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

The documentation page for the Standard Library, https://docs.python.org/3/library/, still says "Python 3.8.6 documentation" in the title. When visiting https://docs.python.org/3.9/library/ (emphasis on the 3.9) explicitly, the correct title is shown. I suspect there are other pages like this, perhaps ones that have not been modified since Python 3.8.6? This is possibly in fact some sort of bug in Sphinx, but I don't think so.

----------
assignee: docs at python
components: Documentation
messages: 378394
nosy: docs at python, pxeger
priority: normal
severity: normal
status: open
title: Docs Standard Library index page has incorrect version in title
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 10 09:22:37 2020
From: report at bugs.python.org (Dustin Moriarty)
Date: Sat, 10 Oct 2020 13:22:37 +0000
Subject: [New-bugs-announce] [issue41998] JSON Encoder Injection Using Indent
Message-ID: <1602336157.61.0.232979425714.issue41998@roundup.psfhosted.org>


New submission from Dustin Moriarty <dustin.moriarty at protonmail.com>:

It is possible to inject data while encoding json when a string is passed to the indent argument. 

Here is an example of an injection attack.

```python
import json

data = {"a": "original data"}
indent = '"b": "injected data",\n'
json_string = json.dumps(data, indent=indent)
print(json_string)
```

Output:
```
{
"b": "injected data",
"a": "original data"
}
```

This is a vulnerability because it is common for CLI and web frameworks to use string as the default data type for arguments. The vulnerability is more likely to be realized for CLI applications where there is more likely to be a use case for exposing the indent parameter to external users in order to control the json output. While this could be prevented by the application using the json encoder, the potential attach vector is not obvious or clear to developers. I cannot see any use case for allowing strings to be passed as indent, so I propose that indent is cast to integer on __init__ of the encoder. I will submit a corresponding PR.

----------
components: Library (Lib)
messages: 378395
nosy: DustinMoriarty
priority: normal
severity: normal
status: open
title: JSON Encoder Injection Using Indent
type: security
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 10 10:40:53 2020
From: report at bugs.python.org (sajicek)
Date: Sat, 10 Oct 2020 14:40:53 +0000
Subject: [New-bugs-announce] [issue41999] imaplib Time2Internaldate crashing
 with time.struct_time supplied from datetime.timetuple()
Message-ID: <1602340853.75.0.0765560089646.issue41999@roundup.psfhosted.org>


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

Hello
first of all, I couldn't find any issue related to this, so sorry if it has been solved before.

There seems to be an issue with IMAPLIB in all versions I've checked, when using the Time2Internaldate function with time.struct_time created by datetime.timetuple() extracted from an EmailMessage object (using the email.utils.parsedate_to_datetime function), and even when created with datetime.now() the function crashes the app with
"TypeError: unsupported type for timedelta seconds component: NoneType"
on line 1530 in current master on GH. (delta = timedelta(seconds=gmtoff))

Crash happens because the "date_time.tm_gmtoff" from which the gmtoff variable is constructed, seems to default to None in all instances of time.struct_time object created by datetime.timetuple(), which still passes the try, except clausule on 1520, because it's not an AttributeError. The time.localtime() metioned in the docs asigns the correct value into tm_gmtoff, but the datetime.timetuple() does not.


Possible solutions I've found:
1) inside Time2Internaldate: surround the delta with try and except - in except make the delta = 0
2) inside Time2Internaldate: check the gmtoff for None and if yes, then change it to 0
3) change the default of tm_gmtoff in timetuple from None to 0 (or to a current timezone offset)

or just say in the docs, that time.struct_time created this way (using the datetime.timetuple()) is unsupported

PS: when writing this issue, I've started thinking this might be a datetime lib issue too

----------
components: Library (Lib)
messages: 378409
nosy: sajicek
priority: normal
severity: normal
status: open
title: imaplib Time2Internaldate crashing with time.struct_time supplied from datetime.timetuple()
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 10 11:58:31 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 10 Oct 2020 15:58:31 +0000
Subject: [New-bugs-announce] [issue42000] Small cleanups to AST-related code
Message-ID: <1602345511.41.0.393317645505.issue42000@roundup.psfhosted.org>


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


----------
components: Interpreter Core
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Small cleanups to AST-related code
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 10 15:02:51 2020
From: report at bugs.python.org (Kaushal Rohit)
Date: Sat, 10 Oct 2020 19:02:51 +0000
Subject: [New-bugs-announce] [issue42001] Deprecate `typing.io` Wrapper
 Namespace
Message-ID: <1602356571.41.0.0517302628029.issue42001@roundup.psfhosted.org>


New submission from Kaushal Rohit <rohit.kg98 at gmail.com>:

The `typing` module has a wrapper namespace in it called `typing.io` which contain I/O stream types.

These types are now a part of the `typing` module itself.

While we are at it, should we also deprecate `typing.re`?

----------
components: Library (Lib)
messages: 378412
nosy: rohitkg98
priority: normal
severity: normal
status: open
title: Deprecate `typing.io` Wrapper Namespace
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/issue42001>
_______________________________________

From report at bugs.python.org  Sat Oct 10 17:01:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2020 21:01:19 +0000
Subject: [New-bugs-announce] [issue42002] Clean up initialization of the sys
 module
Message-ID: <1602363679.37.0.37649342786.issue42002@roundup.psfhosted.org>


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

_PySys_InitCore() and _PySys_InitMain() in Python/sysmodule.c contains many invocations of macros for setting attributes of the sys module. The proposed PR changes these macros.

1. SET_SYS_FROM_STRING was renamed to just SET_SYS. It is much shorter and allow to write many invocations in one line. Also SET_SYS_FROM_STRING was not consistent with SET_SYS_FROM_WSTR.

2. Added new SET_SYS_FROM_STRING which sets attribute specified as C char string (similarly to SET_SYS_FROM_WSTR which sets attribute specified as C wchar_t string).

3. Added COPY_SYS_ATTR for making a copy of the attribute. It uses PyMapping_GetItemString() instead of PyDict_GetItemString() which silences all expressions.

4. Removed SET_SYS_FROM_STRING_BORROW. It no longer used, and it was used improperly.

5. SET_SYS_FROM_STRING_INT_RESULT replaced with SET_SYS.

6. All macros have been rewritten in term of SET_SYS that significantly simplifies the code.

All this makes the code clearer and makes errors handling more correct.

----------
components: Interpreter Core
messages: 378415
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Clean up initialization of the sys module
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 10 19:54:23 2020
From: report at bugs.python.org (foxpython_2020)
Date: Sat, 10 Oct 2020 23:54:23 +0000
Subject: [New-bugs-announce] [issue42003] After changing to list or tuple,
 will the original parameter change?
Message-ID: <1602374063.78.0.592326077925.issue42003@roundup.psfhosted.org>


New submission from foxpython_2020 <foxtable at qq.com>:

c = dict(zip(['one', 'two', 'three'], [1, 2, 3]))
print("1:",c) # right: {'one': 1, 'two': 2, 'three': 3}

b= zip(['one', 'two', 'three'], [1, 2, 3])
a= list(b) #Because of this line of code, the result is different
print("2:",dict(b)) #wrong: {}

b= zip(['one', 'two', 'three'], [1, 2, 3])
a= tuple(b) #Because of this line of code, the result is different
print("2:",dict(b)) #wrong: {}

----------
messages: 378417
nosy: foxpython_2020
priority: normal
severity: normal
status: open
title: After changing to list or tuple, will the original parameter change?

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

From report at bugs.python.org  Sat Oct 10 20:53:17 2020
From: report at bugs.python.org (Javier Ayres)
Date: Sun, 11 Oct 2020 00:53:17 +0000
Subject: [New-bugs-announce] [issue42004] Allow uploading files with
 SimpleHTTPRequestHandler
Message-ID: <1602377597.5.0.712668345738.issue42004@roundup.psfhosted.org>


New submission from Javier Ayres <javier at lufte.net>:

Hello. I'm a big fan of the http.server module to quickly serve some files in a local network with `python3 -m http.server`. I regularly needed to get some files from other people too, but getting everyone to install/run python3 was not such a simple task. Eventually I wrote a subclass of SimpleHTTPRequestHandler that added a form with a file input and accepted POST requests, so people could also upload files to my computer. I think this would be a fine addition to SimpleHTTPRequestHandler, so I'm attaching a potential patch that implements this and adds a new cli parameter so this feature is only enabled explicitly.

----------
components: Library (Lib)
files: patch
messages: 378418
nosy: lufte
priority: normal
severity: normal
status: open
title: Allow uploading files with SimpleHTTPRequestHandler
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49506/patch

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

From report at bugs.python.org  Sun Oct 11 01:45:17 2020
From: report at bugs.python.org (Zhiming Wang)
Date: Sun, 11 Oct 2020 05:45:17 +0000
Subject: [New-bugs-announce] [issue42005] profile/cProfile CLI should catch
 BrokenPipeError
Message-ID: <1602395117.19.0.101668557354.issue42005@roundup.psfhosted.org>


New submission from Zhiming Wang <zmwangx at gmail.com>:

Since profile/cProfile CLI interface prints a sorted list of stats, using head to limit output to the most relevant entries should be a fairly natural thing to do. Unfortunately, BrokenPipeError isn't caught, causing quite a bit of pollution to the output:

$ python3 -m cProfile -m http.server -h | head
usage: http.server [-h] [--cgi] [--bind ADDRESS] [--directory DIRECTORY]
                   [port]

positional arguments:
  port                  Specify alternate port [default: 8000]

optional arguments:
  -h, --help            show this help message and exit
  --cgi                 Run as CGI Server
  --bind ADDRESS, -b ADDRESS
Traceback (most recent call last):
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 180, in <module>
    main()
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 173, in main
    runctx(code, globs, None, options.outfile, options.sort)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 19, in runctx
    return _pyprofile._Utils(Profile).runctx(statement, globals, locals,
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/profile.py", line 66, in runctx
    self._show(prof, filename, sort)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/profile.py", line 72, in _show
    prof.print_stats(sort)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 42, in print_stats
    pstats.Stats(self).strip_dirs().sort_stats(sort).print_stats()
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/pstats.py", line 431, in print_stats
    self.print_line(func)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/pstats.py", line 513, in print_line
    print(f8(tt/nc), end=' ', file=self.stream)
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe

I think the exception should be caught in order to suppress this noise.

----------
components: Library (Lib)
messages: 378421
nosy: zmwangx
priority: normal
severity: normal
status: open
title: profile/cProfile CLI should catch BrokenPipeError
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct 11 10:36:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Oct 2020 14:36:40 +0000
Subject: [New-bugs-announce] [issue42006] Stop using PyDict_GetItem,
 PyDict_GetItemString and _PyDict_GetItemId
Message-ID: <1602427000.44.0.391654139767.issue42006@roundup.psfhosted.org>


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

There are design flaws in PyDict_GetItem(), PyDict_GetItemString() and _PyDict_GetItemId().

1. They suppress all exceptions raised internally. Most common of are MemoryError, KeyboardInterrupt and RecursionError whose raising is out of control of the programmer. When an exception is suppressed the function returns incorrect result. For example PyDict_GetItem() can return NULL for existing key if the user press Ctrl-C.

This situation seems impossible if the key and all keys in the dict are exact strings, but we cannot be sure.

2. PyDict_GetItem() preserves the current exception, and therefore can be used in handling exception but PyDict_GetItemString() and _PyDict_GetItemId() clear it if the creation of string object is failed (due to MemoryError or, less likely, UnicodeDecodeError). It can leads to very unexpected result.

Most of uses of PyDict_GetItem() etc were fixed in issue35459 and other issues. But some occurrences were left, in cases when there is no any error handling, either errors are not expected or all exceptions are suppressed in any case. It is mainly in the compiler and symtable (where we look up in just created dicts), in structseq.c and in the sys module.

The proposed PR (it can be split on several smaller PRs if needed, see also issue41993 and issue42002) removes all calls of PyDict_GetItem, PyDict_GetItemString and _PyDict_GetItemId, replacing them with calls of PyDict_GetItemWithError, _PyDict_GetItemStringWithError and _PyDict_GetItemIdWithError or other functions if appropriate.

_PyDict_GetItemId is no longer used and can be removed.

----------
components: Extension Modules, Interpreter Core
messages: 378437
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Stop using PyDict_GetItem, PyDict_GetItemString and _PyDict_GetItemId
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct 11 13:59:27 2020
From: report at bugs.python.org (veganaiZe)
Date: Sun, 11 Oct 2020 17:59:27 +0000
Subject: [New-bugs-announce] [issue42007] Line continuation after Boolean
 operation
Message-ID: <1602439167.7.0.635101200661.issue42007@roundup.psfhosted.org>


New submission from veganaiZe <veganaiZe-bot at yahoo.com>:

I can't do something like this (regarding the `or`)...

    if (not position.x == 0 and velocity == -1) or
            (not position.x == 500 and velocity == 1)

Nor this...

    if (not position.x == 0 and velocity == -1) or (
            not position.x == 500 and velocity == 1)

I have to do something like this...

    if (not position.x == 0 and velocity == -1) \
           or (not position.x == 500 and velocity == 1)

I would like to be able to do it the first way.

----------
components: Interpreter Core
messages: 378441
nosy: veganaiZe
priority: normal
severity: normal
status: open
title: Line continuation after Boolean operation
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sun Oct 11 17:52:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Oct 2020 21:52:41 +0000
Subject: [New-bugs-announce] [issue42008] Internal Random class calling
 seed() with incorrect argument
Message-ID: <1602453161.68.0.0739681342621.issue42008@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The C code in random_new() incorrectly calls random_seed() with an args tuple. Instead, it should use first element of the args tuple.

This matters because we've deprecated using PyObject_Hash() in random_seed().  Once that is removed, _random.Random(someseed) won't work at all (there's a test for it).

# Public API is correct
>>> from random import Random
>>> r = Random()
>>> r.seed(8675309)
>>> r.random()
0.40224696110279223
>>> r = Random(8675309)
>>> r.random()
0.40224696110279223

# Private API is incorrect for Random(someseed)
>>> from _random import Random
>>> r = Random()
>>> r.seed(8675309)
>>> r.random()
0.40224696110279223
>>> r = Random(8675309)              
>>> r.random()
0.21095576307886765                  <=== This is wrong

----------
components: Extension Modules
keywords: easy (C)
messages: 378457
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Internal Random class calling seed() with incorrect argument
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 02:25:42 2020
From: report at bugs.python.org (Chris Burr)
Date: Mon, 12 Oct 2020 06:25:42 +0000
Subject: [New-bugs-announce] [issue42009] Unable to compile with message
 compiler due to source order
Message-ID: <1602483942.71.0.834700001861.issue42009@roundup.psfhosted.org>


New submission from Chris Burr <christopher.burr at cern.ch>:

Since bpo-36302 was implemented, extension sources are now sorted for reproducibility. This is causing an issue in pywin32 as the *.mc files must be processed first to ensure the *.h files are generated before trying to compile the actual sources. I'm not very familiar with Windows but there are more details in: https://github.com/mhammond/pywin32/issues/1590

As suggested in the issue, the solution is probably to modify msvccompiler.py to process the .rc and .mc files before any C/C++ sources.

----------
components: Distutils
messages: 378471
nosy: chrisburr, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Unable to compile with message compiler due to source order
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 03:46:12 2020
From: report at bugs.python.org (Ken Jin)
Date: Mon, 12 Oct 2020 07:46:12 +0000
Subject: [New-bugs-announce] [issue42010] GenericAlias accepts
 indexing/subscripting, causing confusion
Message-ID: <1602488772.63.0.453170836227.issue42010@roundup.psfhosted.org>


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

While writing the docs for PEP 585's GenericAlias, I noticed that the following anti-pattern described in PEP 585 no longer throws an error when it should:

>>> l = list
>>> l[-1]

Whereas in versions of Python before 3.9, a "TypeError: 'type' object is not subscriptable" would have been thrown.

Quoting PEP 585 again: "Say, if a user is mistakenly passing a list type instead of a list object to a function, and that function is indexing the received object, the code would no longer raise an error."

Although the context of that statement isn't the same. I fully agree with its reasoning. This makes Python more confusing for beginners coming from other languages too:

// in c, makes a 10 element array 
int l[10];

# now in python, this is fine
l[10] 

This may give beginners the false impression that an empty 10 element list has been created.

I have created a PR and a test for this. The changed code blocks ints, floats, bools and complex from indexing for type objects. str is allowed since list['mytype'] seems analogous to typing.List[ForwardRef('mytype')]. Also, imo beginners are unlikely to accidentally write that code while intending to index a list.

Feedback is greatly appreciated, as I've not touched the C codebase in cpython before. Thanks!

----------
components: Interpreter Core
messages: 378475
nosy: kj
priority: normal
severity: normal
status: open
title: GenericAlias accepts indexing/subscripting, causing confusion
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 05:00:43 2020
From: report at bugs.python.org (Riccardo Coccioli)
Date: Mon, 12 Oct 2020 09:00:43 +0000
Subject: [New-bugs-announce] [issue42011] Documentation for
 logging.Filter.filter reports the wrong return type
Message-ID: <1602493243.32.0.577845482202.issue42011@roundup.psfhosted.org>


New submission from Riccardo Coccioli <rcoccioli at gmail.com>:

The documentation for the logging.Filter().filter() method states:

#-----
Is the specified record to be logged? Returns 0 for no, nonzero for yes. If deemed appropriate, the record may be modified in-place.
#-----

While its implementation returns a boolean in Lib/logging/__init__.py.
Moreover the most recent version of mypy (0.790) reports it as an error if a custom class inherit from logging.Filter and implement a filter() method that returns an int as specified in the documentation:

#-----
error: Return type "int" of "filter" incompatible with return type "bool" in supertype "Filter"  [override]
#-----

P.S. As a side note, the API for filter() is quite counter-intuitive as it requires the filter() method to return False to filter out the record and True to include it.

----------
assignee: docs at python
components: Documentation
messages: 378480
nosy: Riccardo Coccioli, docs at python
priority: normal
severity: normal
status: open
title: Documentation for logging.Filter.filter reports the wrong return type
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 06:17:09 2020
From: report at bugs.python.org (Sebastian Rittau)
Date: Mon, 12 Oct 2020 10:17:09 +0000
Subject: [New-bugs-announce] [issue42012] typing support in wsgiref
Message-ID: <1602497829.72.0.629140964099.issue42012@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

In typeshed (the repository for stdlib type annotations), we have defined a bunch of types to support annotating WSGI interfaces. See https://github.com/python/typeshed/blob/master/stdlib/2and3/_typeshed/wsgi.pyi for the current version. Unfortunately these types are only available at type check time, which means that users need to do some gymnastics to use them in their own code.

I think it would be worthwhile to add these types directly to wsgiref or to a new module (e.g. wsgiref.types). On the one hand users could use them at runtime easily, on the other hand they serve as additional documentation WSGI types. In my experience, WSGI applications and middleware often slightly misimplement the standard, which can make interoperability difficult. Both type checking and concrete documentation could help alleviate this problem.

If the maintainers think this would be a good idea, I could provide a PR for both the types and the Python documentation.

----------
components: Library (Lib)
messages: 378484
nosy: srittau
priority: normal
severity: normal
status: open
title: typing support in wsgiref
type: enhancement

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

From report at bugs.python.org  Mon Oct 12 06:55:28 2020
From: report at bugs.python.org (Bernat Gabor)
Date: Mon, 12 Oct 2020 10:55:28 +0000
Subject: [New-bugs-announce] [issue42013] venv on Windows with symlinks is
 broken if invoked with -I
Message-ID: <1602500128.27.0.409801171694.issue42013@roundup.psfhosted.org>


New submission from Bernat Gabor <gaborjbernat at gmail.com>:

Here's a small reproducible, run it on a Windows OS that has symlinks enabled:

import shutil
import venv
import subprocess

shutil.rmtree("venv", ignore_errors=True)
venv.EnvBuilder(with_pip=False, symlinks=True).create("venv")

# works
subprocess.check_call(["venv\\Scripts\\python.exe", "-c", "import sys; print(sys.executable)"])

# fails with No module named 'encodings'
subprocess.check_call(["venv\\Scripts\\python.exe", "-Ic", "import sys; print(sys.executable)"])

----------
messages: 378485
nosy: gaborjbernat
priority: normal
severity: normal
status: open
title: venv on Windows with symlinks is broken if invoked with -I
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 08:54:15 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIMSMaWhhxZk=?=)
Date: Mon, 12 Oct 2020 12:54:15 +0000
Subject: [New-bugs-announce] [issue42014] shutil.rmtree calls onerror with
 different function than failed
Message-ID: <1602507255.43.0.726203818853.issue42014@roundup.psfhosted.org>


New submission from Michal ?iha? <michal at cihar.com>:

The onerror callback is called with os.lstat when the actual failing function is os.open.

To reproduce create directory that can not be listed:

import os
import shutil

def onerror(func, path, exc_info):
    print(func)

os.mkdir("test")
os.chmod("test", 0)
shutil.rmtree("test", onerror=onerror)

----------
components: Library (Lib)
messages: 378495
nosy: nijel
priority: normal
pull_requests: 21642
severity: normal
status: open
title: shutil.rmtree calls onerror with different function than failed
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 10:23:44 2020
From: report at bugs.python.org (Yannick Jadoul)
Date: Mon, 12 Oct 2020 14:23:44 +0000
Subject: [New-bugs-announce] [issue42015] Order of decrementing reference
 counts in meth_dealloc
Message-ID: <1602512624.15.0.894803367223.issue42015@roundup.psfhosted.org>


New submission from Yannick Jadoul <yannick.jadoul at gmail.com>:

In Python 3.9, the line `Py_XDECREF(PyCFunction_GET_CLASS(m));` was added to `meth_dealloc` (in `methodobject.c`). Unfortunately for pybind11, it's inserted exactly two lines too low, since it accesses the `PyMethodDef` and we store the `PyMethodDef` instance in the capsule that's used as `self`-argument of the `PyCFunction`.

Result: UB, since `Py_XDECREF(m->m_self);` brings down the refcount of the capsule to 0 and (indirectly) frees the `PyMethodDef`, while its contents are now still accessed.

>From the pybind11 perspective, it would be optimal if this could be fixed in CPython itself, by moving up this one `Py_XDECREF` 2 lines. This would a) be more efficient than creating a workaround, and b) allow old, existing versions of pybind11 to work with Python 3.9 (well, 3.9.1, then, hopefully); the user base of pybind11 has grown quite a bit and now includes giants like scipy or some Google libraries.
I will make a PR implementing this, soon.

If there's a different, recommended way of creating these `PyCFunctionObject`s dynamically and cleaning up the `PyMethodDef`, we'd be interested as well, to make sure these kinds of breakages are avoided in the future.

Apologies for only figuring out now how to debug this, using valgrind. Up until yesterday, we only saw some failures in CI on macOS, but it was hard to reproduce and debug locally.


- Related issue: https://bugs.python.org/issue41237
- pybind11 issue: https://github.com/pybind/pybind11/issues/2558
- pybind11 PR: https://github.com/pybind/pybind11/pull/2576

----------
components: C API, Interpreter Core
messages: 378500
nosy: YannickJadoul
priority: normal
severity: normal
status: open
title: Order of decrementing reference counts in meth_dealloc
type: crash
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 11:29:24 2020
From: report at bugs.python.org (Fibonacci)
Date: Mon, 12 Oct 2020 15:29:24 +0000
Subject: [New-bugs-announce] [issue42016] Add ksh to venv examples
Message-ID: <1602516564.28.0.841153508443.issue42016@roundup.psfhosted.org>


New submission from Fibonacci <python at academicsolutions.ch>:

Add an example on how to source with the korn shell (tested on OpenBSD). Maybe the bash/zsh example can be changed to use the dot to source the file, then it could be included there.

Diff attached.

----------
assignee: docs at python
components: Documentation
files: python_venv_ksh
messages: 378504
nosy: docs at python, fibonacci
priority: normal
severity: normal
status: open
title: Add ksh to venv examples
type: enhancement
Added file: https://bugs.python.org/file49509/python_venv_ksh

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

From report at bugs.python.org  Mon Oct 12 11:41:05 2020
From: report at bugs.python.org (ThatXliner)
Date: Mon, 12 Oct 2020 15:41:05 +0000
Subject: [New-bugs-announce] [issue42017] Add new type in typing
Message-ID: <1602517265.37.0.00250446603223.issue42017@roundup.psfhosted.org>


New submission from ThatXliner <bryan.hu.2020 at gmail.com>:

Because there is a typing.AnyStr (which is equal to AnyStr = TypeVar("AnyStr", str, bytes)), I think there should be a AnyNum which is equivalent to

from decimal import Decimal
from fractions import Fraction
AnyNum = TypeVar("AnyNum", int, float, complex, Decimal, Fraction)

----------
components: Library (Lib)
messages: 378505
nosy: ThatXliner
priority: normal
severity: normal
status: open
title: Add new type in typing
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 12 12:21:08 2020
From: report at bugs.python.org (Kevin Wojniak)
Date: Mon, 12 Oct 2020 16:21:08 +0000
Subject: [New-bugs-announce] [issue42018] winreg SetValue(Ex) should mention
 integer as an acceptable value
Message-ID: <1602519668.67.0.657607814391.issue42018@roundup.psfhosted.org>


New submission from Kevin Wojniak <kwojniak at box.com>:

On https://docs.python.org/3/library/winreg.html

For SetValue and SetValueEx is says:

> value is a string that specifies the new value.

but value can also be an integer if the type is DWORD. Here's a test that shows that: https://github.com/python/cpython/blob/3.9/Lib/test/test_winreg.py#L339

Suggested update:

> value is a string or integer that specifies the new value.

----------
assignee: docs at python
components: Documentation
messages: 378508
nosy: docs at python, kwojniak_box
priority: normal
severity: normal
status: open
title: winreg SetValue(Ex) should mention integer as an acceptable value
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 12 14:26:39 2020
From: report at bugs.python.org (Aristotelis Mikropoulos)
Date: Mon, 12 Oct 2020 18:26:39 +0000
Subject: [New-bugs-announce] [issue42019] Override MagicMock special methods
Message-ID: <1602527199.87.0.454087859253.issue42019@roundup.psfhosted.org>


New submission from Aristotelis Mikropoulos <amikrop at gmail.com>:

This is more of a question whether the following is intended behavior:
Subclassing unittest.mock.MagicMock and overriding one of the special (double underscore) methods has no effect. The default MagicMock method implementation still stands. This isn't the case with subclassing Mock.
It is understood that the purpose of MagicMock is to offer stub implementations of certain special methods, but isn't defining them yourself in the body of a subclass supposed to override those stubs?
There is an example in the file attached.

----------
components: Tests
files: mockcase.py
messages: 378513
nosy: Indy
priority: normal
severity: normal
status: open
title: Override MagicMock special methods
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49510/mockcase.py

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

From report at bugs.python.org  Mon Oct 12 14:50:52 2020
From: report at bugs.python.org (denis)
Date: Mon, 12 Oct 2020 18:50:52 +0000
Subject: [New-bugs-announce] [issue42020] interpreter hangs forever on
 invalid input
Message-ID: <1602528652.49.0.982690015105.issue42020@roundup.psfhosted.org>


New submission from denis <gantsevdenis at gmail.com>:

Python 3.8.5, Python 3.7.3
When trying to print invalid unicode, interpreter goes to a completely unresponsive state

>>> print("\x9b")


eyboardInterrupt
>>> print("\xa5")
?
>>> print("\x95")

>>> print("\x90")
denis at debian:~$ <interpreter hangs forever, ctrl+d was pressed to exit>

----------
components: Unicode
messages: 378514
nosy: dgan, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: interpreter hangs forever on invalid input
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Oct 12 15:18:40 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 12 Oct 2020 19:18:40 +0000
Subject: [New-bugs-announce] [issue42021] Fix possible ref. leaks in
 _sqlite3 module initialisation
Message-ID: <1602530320.77.0.149303517961.issue42021@roundup.psfhosted.org>


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

Handle PyDict_SetItemString() errors in _sqlite3 init by dereferencing the item object and then goto error.

----------
components: Library (Lib)
messages: 378516
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Fix possible ref. leaks in _sqlite3 module initialisation
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 12 16:43:50 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Mon, 12 Oct 2020 20:43:50 +0000
Subject: [New-bugs-announce] [issue42022] Allow ensurepip to work without
 bundled wheels
Message-ID: <1602535430.83.0.251660396877.issue42022@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

Some Linux distributions, such as Debian, have guidelines against shipping things like prebuilt wheels.

Taking Debian as an example, they remove the pip and setuptools wheels and consequently break ensurepip. This also has some implications in the venv module.

As a way to fix this, I would like to propose for ensurepip to install .pth files pointing to the pip and setuptools packages in purelib/platlib.

This behavior could either be switched on by a flag in the makefile or, maybe, if the wheels are not found.

Do you think this would be a reasonable approach?
Currently, we cannot rely on the ensurepip to work. Some projects that really need it are shipping a vendored version of the module.

----------
components: Library (Lib)
messages: 378524
nosy: FFY00, dstufft, ncoghlan, p-ganssle, pradyunsg
priority: normal
severity: normal
status: open
title: Allow ensurepip to work without bundled wheels
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 12 17:18:16 2020
From: report at bugs.python.org (ThatXliner)
Date: Mon, 12 Oct 2020 21:18:16 +0000
Subject: [New-bugs-announce] [issue42023] Argparse: Add a "display" arg
Message-ID: <1602537496.16.0.894148688163.issue42023@roundup.psfhosted.org>


New submission from ThatXliner <bryan.hu.2020 at gmail.com>:

In argparse, I've always wanted a way to make colored help text like those of poetry and pipenv. But argparse's show help isn't well documented (Therefore, I can't find a way to completely modify the help text), and the metavar arg isn't really helpful. I want to do something like this:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument("foo", help="To foo a bar", display="FOO!!!!")
>>> parser.print_help()

usage: main.py [-h] foo

positional arguments:
  FOO!!!!     To foo a bar

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

>>>

That way, I can colorize the help output.

----------
components: Library (Lib)
messages: 378526
nosy: ThatXliner
priority: normal
severity: normal
status: open
title: Argparse: Add a "display" arg
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Oct 13 01:15:39 2020
From: report at bugs.python.org (jayesh)
Date: Tue, 13 Oct 2020 05:15:39 +0000
Subject: [New-bugs-announce] [issue42024] Exception ignored in: <function
 WeakValueDictionary.__init__.<locals>.remove at 0x7f6a325f2ea0>
Message-ID: <1602566139.42.0.455519135805.issue42024@roundup.psfhosted.org>


New submission from jayesh <jaymahajan28 at gmail.com>:

Team,

I am getting python warning messages while run ansible.
Previously I was using python 3.5.3, but after read the below article, I upgraded it with python 3.5.4. 

ref: https://github.com/ansible/ansible/issues/21982

Still facing the same issues. Kindly find attached logs for the same and help us to solve this issue.

Thanks

----------
files: pthon-warning-3.5.4.txt
messages: 378539
nosy: jayesh007
priority: normal
severity: normal
status: open
title: Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f6a325f2ea0>
type: compile error
versions: Python 3.5
Added file: https://bugs.python.org/file49513/pthon-warning-3.5.4.txt

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

From report at bugs.python.org  Tue Oct 13 05:01:16 2020
From: report at bugs.python.org (David Grellscheid)
Date: Tue, 13 Oct 2020 09:01:16 +0000
Subject: [New-bugs-announce] [issue42025] zoneinfo: fold not taken into
 account in time difference when tzinfo is equal
Message-ID: <1602579676.45.0.837169580708.issue42025@roundup.psfhosted.org>


New submission from David Grellscheid <d.grellscheid at gmail.com>:

I'm comparing two aware timestamps during a clock transition that differ only in their fold= value.

When taking the difference of two aware timestamps with the *same* tzinfo, the fold parameter is ignored. 

A difference between two timestamps with different tzinfo works correctly, with fold taken into account.

For the attached code I would expect all timedeltas to be the same, but I get:

0:00:00 Oslo_1   - Oslo_0
1:00:00 Berlin_1 - Oslo_0
1:00:00 Oslo_1   - Berlin_0
0:00:00 Berlin_1 - Berlin_0

----------
components: Library (Lib)
files: fold_bug.py
messages: 378545
nosy: d.grellscheid
priority: normal
severity: normal
status: open
title: zoneinfo: fold not taken into account in time difference when tzinfo is equal
versions: Python 3.9
Added file: https://bugs.python.org/file49514/fold_bug.py

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

From report at bugs.python.org  Tue Oct 13 05:28:18 2020
From: report at bugs.python.org (Chetan Palliwal)
Date: Tue, 13 Oct 2020 09:28:18 +0000
Subject: [New-bugs-announce] [issue42026] index function return first index
 for same element if repetitive in a list
Message-ID: <1602581298.61.0.984431029548.issue42026@roundup.psfhosted.org>


New submission from Chetan Palliwal <Chetanjain1313 at gmail.com>:

In [1]: po=[11,22,33,44,11,55,66,11,88]


In [2]: for lm in po:
   ...:     if lm==11:
   ...:         print("value is = {} and index is = {}".format(lm,po.index(lm)))
   ...:     else:
   ...:         print("value is = {} and index is = {}".format(lm,po.index(lm)))
   ...:
value is = 11 and index is = 0
value is = 22 and index is = 1
value is = 33 and index is = 2
value is = 44 and index is = 3
value is = 11 and index is = 0
value is = 55 and index is = 5
value is = 66 and index is = 6
value is = 11 and index is = 0
value is = 88 and index is = 8

----------
components: Library (Lib)
messages: 378546
nosy: chetanpalliwal13
priority: normal
severity: normal
status: open
title: index function return first index for same element if repetitive in a list
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 13 14:36:52 2020
From: report at bugs.python.org (Colin)
Date: Tue, 13 Oct 2020 18:36:52 +0000
Subject: [New-bugs-announce] [issue42027] /passive run of Windows installer
 fail silently on Win7
Message-ID: <1602614212.55.0.749302354325.issue42027@roundup.psfhosted.org>


New submission from Colin <colin.bounouar at gmail.com>:

As expected, Python 3.9.0 cannot be installed on Windows 7. 

Running the installer displays a message clearly stating this. 

However, running the installer in passive mode (/passive) is expected to display errors that might occur. As stated in https://docs.python.org//3.9/using/windows.html#installing-without-ui

But this is not the case, nothing is displayed when launching the installer in passive mode.

I would expect the same message as in the UI.

----------
components: Installation, Windows
messages: 378572
nosy: colin-b, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: /passive run of Windows installer fail silently on Win7
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 13 17:15:02 2020
From: report at bugs.python.org (xpdseth)
Date: Tue, 13 Oct 2020 21:15:02 +0000
Subject: [New-bugs-announce] [issue42028] Regression in mimetypes for
 image/bmp
Message-ID: <1602623702.59.0.922962266093.issue42028@roundup.psfhosted.org>


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

Please check the following short examples of the issue:

Status: Downloaded newer image for python:3.7.4
Python 3.7.4 (default, Oct 17 2019, 05:59:21)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> str(mimetypes.guess_extension('image/bmp'))
'.bmp'


Status: Downloaded newer image for python:3.7.5
Python 3.7.5 (default, Nov 23 2019, 05:59:34)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> str(mimetypes.guess_extension('image/bmp'))
'None'
>>>

Status: Downloaded newer image for python:latest
Python 3.9.0 (default, Oct  6 2020, 21:52:53)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> str(mimetypes.guess_extension('image/bmp'))
'None'


I believe the issue is introduced here by duplicating the bmp key in types_map/_types_map_default

'.bmp'    : 'image/bmp'
https://github.com/python/cpython/pull/14375/files#diff-aed43839a49bace08b60186baa4b27ad69ecd6b61f928bd696b4fb670750774fR490

 '.bmp'    : 'image/x-ms-bmp',
https://github.com/python/cpython/pull/14375/files#diff-aed43839a49bace08b60186baa4b27ad69ecd6b61f928bd696b4fb670750774fR502

----------
components: Library (Lib)
messages: 378577
nosy: xpdseth
priority: normal
pull_requests: 21656
severity: normal
status: open
title: Regression in mimetypes for image/bmp
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 13 19:57:55 2020
From: report at bugs.python.org (Kevin)
Date: Tue, 13 Oct 2020 23:57:55 +0000
Subject: [New-bugs-announce] [issue42029] Remove dynload_dl.c
Message-ID: <1602633475.18.0.479019652279.issue42029@roundup.psfhosted.org>


New submission from Kevin <kadler at us.ibm.com>:

dynload_dl.c is no longer referenced anywhere in the code. It was used to support dynamic loading on IRIX 4 and DYNIX, but those platforms were dropped in https://github.com/cpython/cpython/commit/b9949dbe6c20537b7821f25fc1eeb4e7f3faabff. Considering that commit removes all references to dynload_dl, I suspect it was an oversight that it was not removed in that commit.

----------
components: Interpreter Core
messages: 378586
nosy: kadler
priority: normal
severity: normal
status: open
title: Remove dynload_dl.c

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

From report at bugs.python.org  Tue Oct 13 20:08:54 2020
From: report at bugs.python.org (Kevin)
Date: Wed, 14 Oct 2020 00:08:54 +0000
Subject: [New-bugs-announce] [issue42030] Drop support for dynload_aix
Message-ID: <1602634134.46.0.704375608696.issue42030@roundup.psfhosted.org>


New submission from Kevin <kadler at us.ibm.com>:

Python has supported using dynload_shlib (using dlopen) on AIX since https://github.com/python/cpython/commit/c19c5a62aef7dce0e8147655b0d2f087965fae75 in 2003. While I have not found a definitive timeline of when AIX gained support for dlopen, I have found references going back to at least 2000. Considering this is now 20 years later and all supported AIX versions support dlopen, I suspect nobody has used or tested this code path in quite some time. I propose removing this support under PEP 11.

----------
components: Interpreter Core
messages: 378588
nosy: kadler
priority: normal
severity: normal
status: open
title: Drop support for dynload_aix

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

From report at bugs.python.org  Wed Oct 14 00:52:04 2020
From: report at bugs.python.org (Kevin Kuan)
Date: Wed, 14 Oct 2020 04:52:04 +0000
Subject: [New-bugs-announce] [issue42031] os.makedirs() introduces high
 memory usage for explorer.exe
Message-ID: <1602651124.31.0.715592568811.issue42031@roundup.psfhosted.org>


New submission from Kevin Kuan <kevin.kuan.trend at gmail.com>:

Hi,
I would like to report bug for os.makedirs().
I am running this script on Windows 10 1909 (most win10 work), python 3.8.1.

 
os.makedirs() is making explorer.exe huge amount of memory and crashing the system after only 3 hours.
After changing that line to subprocess.run('mkdir ...') memory usage is reduced significantly.After changing all shutil functions as well, memory usage will not grow. 

(This is my first time community contribution. If anything, please let me know.)
Kevin Kuan 
(kevin.kuan.trend at gmail.com)


-------script.txt------
import time
import logging
import uuid
import subprocess

REPEAT = 10

def new_target_folder():
        TARGET_BASE,
        str(uuid.uuid4().hex)
    )
    os.makedirs(target)
    return target


def delete_folder(target):
    if os.path.exists(target):
        shutil.rmtree(target)



def copy_samples(target):
    shutil.copytree(
        SOURCE_FOLDER, 
        os.path.join(target, 'file_copy_clean_samples')


def copy_file_test():
    for i in range(REPEAT):
        t = new_target_folder()
        copy_samples(t)
        delete_folder(t)

------after.txt------
import os
import shutil
import time
import logging
import uuid
import subprocess

REPEAT = 10

SOURCE_FOLDER = os.path.abspath(
    os.path.join(
        __file__,
        '..',
        '..',
        '_VolumeTestSamples',
        'file_copy_clean_samples',
    )
)

TARGET_BASE = os.path.join(
    os.environ['USERPROFILE'],
    r'Desktop',
    r'sample_file_copy',
    str(uuid.uuid4().hex)
)

PAUSE = 1


def run_for_one_week(func, pause):
    time_start = time.time()
    while True:
        time_now = time.time()
        logging.debug('{}'.format(time_now))
        if time_now - time_start > 1 * 7 * 24 * 60 * 60:
            break
        func()
        time.sleep(pause)


def new_target_folder():
    target = os.path.join(
        TARGET_BASE,
        str(uuid.uuid4().hex)
    )
    subprocess.run(
        ['mkdir', target],
        shell=True
    )
    return target


def delete_folder(target):
    if os.path.exists(target):
        subprocess.run(
            ['rmdir', '/s', '/q', target],
            shell=True
        )


def copy_samples(target):
    subprocess.run(
        ['echo', 'D', '|', 'xcopy', '/s', '/y', SOURCE_FOLDER, target],
        shell=True
    )


def copy_file_test():
    for i in range(REPEAT):
        t = new_target_folder()
        print (t)
        copy_samples(t)
        delete_folder(t)
    

if __name__ == '__main__':
    r = logging.getLogger()
    r.setLevel(logging.DEBUG)
    run_for_one_week(copy_file_test, PAUSE)

----------
components: Windows
files: Image20201014125025.png
messages: 378603
nosy: kevin.kuan.trend, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.makedirs() introduces high memory usage for explorer.exe
versions: Python 3.8
Added file: https://bugs.python.org/file49519/Image20201014125025.png

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

From report at bugs.python.org  Wed Oct 14 04:27:09 2020
From: report at bugs.python.org (Veronica Olsen)
Date: Wed, 14 Oct 2020 08:27:09 +0000
Subject: [New-bugs-announce] [issue42032] Setting PYTHONPYCACHEPREFIX using
 ~ (tilde) creates a "~" folder
Message-ID: <1602664029.5.0.459362621128.issue42032@roundup.psfhosted.org>


New submission from Veronica Olsen <jadzia626 at gmail.com>:

On Debian Bullseye (testing):

Setting

export PYTHONPYCACHEPREFIX=~/.pycache

has previously worked. With Python 3.8.6, this still works in practice, when running python code (the pycache is still redirected), but during initialisation, the python3 executable creates an empty folder named "~" in the folder where the python exec or a python script is run.

Changing the environment variable to:

export PYTHONPYCACHEPREFIX=$HOME/.pycache

resolves the issue.

Expansion of ~ is of course a bit fickly in general, but 

I assume this is not intended. Deleting those folders from command line is rather tricky!

----------
components: Interpreter Core
messages: 378607
nosy: vkbo
priority: normal
severity: normal
status: open
title: Setting PYTHONPYCACHEPREFIX using ~ (tilde) creates a "~" folder
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 14 06:48:31 2020
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 14 Oct 2020 10:48:31 +0000
Subject: [New-bugs-announce] [issue42033] Seemingly unnecessary
 complexification of foo(**kw)
Message-ID: <1602672511.92.0.360571035375.issue42033@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

Following bpo-39320 the highly specialised bytecode for vararg calls were replaced by simpler ones, but there seems to be at least one area where the generated bytecode regressed for possibly no reason?

In Python 3.8, foo(**var) compiles to:

0 LOAD_GLOBAL              0 (foo)
2 BUILD_TUPLE              0
4 LOAD_FAST                2 (var)
6 CALL_FUNCTION_EX         1

In Python 3.9, it compiles to:

0 LOAD_GLOBAL              0 (foo)
2 BUILD_TUPLE              0
4 BUILD_MAP                0
6 LOAD_FAST                2 (var)
8 DICT_MERGE               1
0 CALL_FUNCTION_EX         1

The PR 18141 does not seem to change the implementation of CALL_FUNCTION_EX so I would expect that if it was fine with taking the `var` arbitrary mapping before it stil is now, and the extra two opcodes (and creation of a dict) is unnecessary?

----------
messages: 378613
nosy: Mark.Shannon, xmorel
priority: normal
severity: normal
status: open
title: Seemingly unnecessary complexification of foo(**kw)
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 14 09:47:28 2020
From: report at bugs.python.org (Sagar Pant)
Date: Wed, 14 Oct 2020 13:47:28 +0000
Subject: [New-bugs-announce] [issue42034] Unchecked return in
 Objects/typeobject.c and possible uninitialized variables in cls and
 new_mro
Message-ID: <1602683248.52.0.780024334642.issue42034@roundup.psfhosted.org>


New submission from Sagar Pant <sagpant at microsoft.com>:

The return value of a function that is potentially used to initialize a local variable is not checked. Therefore, reading the local variable may result in undefined behavior.

Our AI analyzer found that this function is called for a total of 43 times. Out of these 43 times, the return value from the function call is checked at 42 instances. This is the only instance where the code misses to check the return value for success or failure.

Once such correct reference usage found in Python/hamt.c at line 2805 .

----------
components: C API
messages: 378615
nosy: sagar
priority: normal
severity: normal
status: open
title: Unchecked return in Objects/typeobject.c and possible uninitialized variables in cls and new_mro
type: enhancement

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

From report at bugs.python.org  Wed Oct 14 09:52:05 2020
From: report at bugs.python.org (fancitron)
Date: Wed, 14 Oct 2020 13:52:05 +0000
Subject: [New-bugs-announce] [issue42035] PyType_GetSlot cannot get tp_name
Message-ID: <1602683525.08.0.938781399322.issue42035@roundup.psfhosted.org>


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

In the Limited API (where PyTypeObject is opaque), there is no way to retrieve the tp_name of a type object.  The PyType_GetSlot() function doesn?t define a slot ID Py_tp_name.  This makes it inconvenient to port existing code to the Limited API.  Is this intentional?  How to work around this?

----------
components: C API
messages: 378616
nosy: fancitron
priority: normal
severity: normal
status: open
title: PyType_GetSlot cannot get tp_name
type: enhancement

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

From report at bugs.python.org  Wed Oct 14 11:21:10 2020
From: report at bugs.python.org (Sagar Pant)
Date: Wed, 14 Oct 2020 15:21:10 +0000
Subject: [New-bugs-announce] [issue42036] Unchecked return in
 Modules/posixmodule.c from multiple function calls
Message-ID: <1602688870.73.0.257118876464.issue42036@roundup.psfhosted.org>


New submission from Sagar Pant <sagpant at microsoft.com>:

The return value of a function that is potentially used to initialize a local variable is not checked. Therefore, reading the local variable may result in undefined behavior.

Our AI analyzer flagged it to be a potential bug as it found another usage of the function in the codebase where the return value of the function was checked for success/failure before using it?s parameters.

----------
components: C API
messages: 378623
nosy: sagar
priority: normal
severity: normal
status: open
title: Unchecked return in Modules/posixmodule.c from multiple function calls
type: enhancement

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

From report at bugs.python.org  Wed Oct 14 11:23:42 2020
From: report at bugs.python.org (Markus Israelsson)
Date: Wed, 14 Oct 2020 15:23:42 +0000
Subject: [New-bugs-announce] [issue42037] Documentation confusion in
 CookieJar functions
Message-ID: <1602689022.88.0.876415237077.issue42037@roundup.psfhosted.org>


New submission from Markus Israelsson <markus.israelsson at surgicalscience.com>:

The documentation in https://docs.python.org/3.8/library/http.cookiejar.html#http.cookiejar.CookieJar
claims the following for functions add_cookie_header and extract_cookies.

***
The request object (usually a urllib.request.Request instance) must support the methods get_full_url(), get_host(), get_type(), unverifiable(), has_header(), get_header(), header_items(), add_unredirected_header() and origin_req_host attribute as documented by urllib.request.
***


When reading the documentation for Request Objects https://docs.python.org/3.8/library/urllib.request.html?highlight=requests#request-objects
there is this:
***
Changed in version 3.4: The request methods add_data, has_data, get_data, get_type, get_host, get_selector, get_origin_req_host and is_unverifiable that were deprecated since 3.3 have been removed.
***

So basically the documentation claims that if the request object does not support functions that are removed then the headers will not be added. The code itself seem to do the correct thing however and add the header.

----------
assignee: docs at python
components: Documentation
messages: 378624
nosy: docs at python, markus
priority: normal
severity: normal
status: open
title: Documentation confusion in CookieJar functions
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 14 13:09:06 2020
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 14 Oct 2020 17:09:06 +0000
Subject: [New-bugs-announce] [issue42038] Tracemalloc's format() doc
 contradictory
Message-ID: <1602695346.39.0.326290965149.issue42038@roundup.psfhosted.org>


New submission from Lisa Roach <lisaroach14 at gmail.com>:

Tracemalloc's format documentation (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Traceback.format) says first:

"Format the traceback as a list of lines with newlines."

then:

"Similar to the traceback.format_tb() function, except that format() does not include newlines."

The first statement is incorrect, tracemalloc does NOT add newlines to the list. I recommend just removing the "with newlines" in the first statement.

----------
assignee: docs at python
components: Documentation
messages: 378636
nosy: docs at python, lisroach
priority: low
severity: normal
status: open
title: Tracemalloc's format() doc contradictory
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/issue42038>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:31:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 14 Oct 2020 18:31:23 +0000
Subject: [New-bugs-announce] [issue42039] Add gc.track and gc.untrack
Message-ID: <1602700283.06.0.781805695704.issue42039@roundup.psfhosted.org>


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

We have C-API calls to track and untrack objects. Having similar calls in Python can be usefull to selectively deactivate the garbage collector for some objects for performance, debugging or testing purposes. For instance, in https://bugs.python.org/issue41984 this could have been very usefull

----------
assignee: pablogsal
components: Interpreter Core
messages: 378645
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Add gc.track and gc.untrack
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 15 01:08:28 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Oct 2020 05:08:28 +0000
Subject: [New-bugs-announce] [issue42040] Change IDLE 'more information'
 splash line, change doc name
Message-ID: <1602738508.01.0.647349013117.issue42040@roundup.psfhosted.org>


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

IDLE currently follows the version and system info line with 
 Type "help", "copyright", "credits" or "license()" for more information.  The last 3 are nearly useless, and duplicate the availability of the documents in a better format from About IDLE, where such things are usually found.  In any case, beginners are not likely to care, and most people will look at most once.

Entering 'help' prints the instruction to enter 'help()' for interaction or 'help(object)' for info on object.

Proposed replacement:
  Type "help" (no quotes) or click Help above for more information.

On macOS, one must click IDLE for About IDLE, but macOS users should know and expect it there (which is why it is moved there on macOS).

Also, the menu entry "IDLE Help" should be "IDLE Doc".  I believe the current entry dates to when "IDLE Help" was a separate text from the IDLE doc rather than a copy thereof.

PR later.

----------
assignee: terry.reedy
components: IDLE
messages: 378663
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Change IDLE 'more information' splash line, change doc name
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct 15 01:50:57 2020
From: report at bugs.python.org (Mark Keller)
Date: Thu, 15 Oct 2020 05:50:57 +0000
Subject: [New-bugs-announce] [issue42041] venv subprocess call to python
 resolves to wrong interpreter
Message-ID: <1602741057.44.0.746329954435.issue42041@roundup.psfhosted.org>


New submission from Mark Keller <markooo.keller at gmail.com>:

Hey,

Wanted to report this weird behavior I saw recently. Let me first explain how to reproduce and then talk about where I think the issue comes from.

I attached a tar.gz file with 2 Python files in it.

Here's how to reproduce:
0. Make sure that pytest is unavailable in your command line, or please edit to another library that you don't have available from another Python install (make sure to update the import statement in `script1.py`).
1. Untar the 2 scripts into current working directory. Note: I reproduced on a Windows VM (Version 10.0.18363 Build 18363).
2. Make a Python 3.7, or 3.8 environment venv. Note: I used Python 3.8.2.
3. Activate venv and install pytest in it.
4. Run `python run_scripts.py` and observe the error.

Note: The same thing works on Python 3.6 as expected.

My team observed this issue when virtualenv released this Monday. It changed how it works with Windows and Python 3.7+, before it was not using the Windows redirect script generated by venv and just worked like how older versions on Windows do.
But what we are seeing is that if you start a subprocess call to `python` then that gets resolved to the system wide Python binary without the venv site-packages being in PYTHONPATH.
So the subprocess will fail when importing pytest in the subprocess.

If this is not clear please don't hesitate to ask me for clarification, or refer to https://github.com/pypa/virtualenv/issues/1981 for more debugging info.

Another interesting thing that I noticed is that if you make a subprocess call to `pytest` instead then that gets resolved correctly.

----------
components: Windows
files: repro.tar.gz
messages: 378665
nosy: keller00, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
status: open
title: venv subprocess call to python resolves to wrong interpreter
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49520/repro.tar.gz

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

From report at bugs.python.org  Thu Oct 15 07:57:21 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 15 Oct 2020 11:57:21 +0000
Subject: [New-bugs-announce] [issue42042] docs.python.org for 3.10 missing
 the new refererence record.
Message-ID: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

For example
https://docs.python.org/3.10/c-api/bool.html?highlight=pydict_new#c.PyDict_New

should display 

`Return value: New reference.`

but not, this looks like a regression bug.

other version display `Return value: New reference.` very well.

----------
assignee: docs at python
components: Documentation
messages: 378677
nosy: corona10, docs at python, vstinner
priority: normal
severity: normal
status: open
title: docs.python.org for 3.10 missing the new refererence record.
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 15 08:03:28 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Pot?=)
Date: Thu, 15 Oct 2020 12:03:28 +0000
Subject: [New-bugs-announce] [issue42043] zipfile.Path should support
 inheritance
Message-ID: <1602763408.56.0.61735130641.issue42043@roundup.psfhosted.org>


New submission from ?tienne Pot <etiennefg.pot at gmail.com>:

Currently, zipfile.Path inheritance behavior is inconsistent with pathlib.Path:

```
class MyPath(zipfile.Path):
  pass


path = MyPath(zf)
path = path.joinpath('other')
assert isinstance(path, MyPath)  # Oups, type(path) is zipfile.Path
```

Calling parent, /,... should keep the class, as for pathlib.Path

Use case: I'm writing a wrapper around `zipfile.Path` which adds `os.fspath` compatibility (the file is extracted in a tmp dir when os.path.join, open,...).

----------
components: Library (Lib)
messages: 378678
nosy: ?tienne Pot
priority: normal
severity: normal
status: open
title: zipfile.Path should support inheritance
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 15 09:22:04 2020
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 15 Oct 2020 13:22:04 +0000
Subject: [New-bugs-announce] [issue42044] Running Python in unbuffered mode
 may not write all contents to the console
Message-ID: <1602768124.79.0.2669254941.issue42044@roundup.psfhosted.org>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

When running Python in unbuffered mode it may fail to write all the contents to the actual console (on Windows).

The code below can reproduce the issue: 

```
import sys
s = ''
for i in range(1,301):
    s += f"{str(i*100).zfill(10)}{'x' * 89}\n"

sys.stdout.write(s)
```

When calling it with `python -u code.py` it'll write only up to line 15000 and when calling it with `python code.py` it'll write up to line 30000.

This fails because in `_textiowrapper_writeflush` it doesn't verify if all the contents have been indeed written and thus fails in a partial write. In buffered mode it works because `_io_BufferedWriter_write_impl` does the job properly.

I'm a bit uncertain on why doesn't `_io__WindowsConsoleIO_write_impl` itself do the loop to write everything instead of leaving it up to callers to do that work (apparently due to issue11395 it says that it only writes partially, but maybe the fix could've been to loop inside of `_io__WindowsConsoleIO_write_impl` to write everything instead of expecting callers to handle partial writes...

----------
components: IO
messages: 378684
nosy: fabioz
priority: normal
severity: normal
status: open
title: Running Python in unbuffered mode may not write all contents to the console
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 15 11:24:27 2020
From: report at bugs.python.org (Augusto Hack)
Date: Thu, 15 Oct 2020 15:24:27 +0000
Subject: [New-bugs-announce] [issue42045] Add support to async code to pdb
Message-ID: <1602775467.01.0.625412494748.issue42045@roundup.psfhosted.org>


New submission from Augusto Hack <me at hak.cx>:

Currently it seems that `pdb` does not support executing `async` functions. This makes debugging `async` code a bit harder if one needs to call an `async` function from the REPL.

Here is an example:

```python
import asyncio

async def f() -> int:
    return 1

async def main():
    breakpoint()

asyncio.run(main())
```

The goal would be to call `f()`. In a real world application this could be additional HTTP requests, database queries, etc.

----------
components: asyncio
messages: 378687
nosy: asvetlov, hack.augusto, yselivanov
priority: normal
severity: normal
status: open
title: Add support to async code to pdb
type: enhancement

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

From report at bugs.python.org  Thu Oct 15 13:36:32 2020
From: report at bugs.python.org (john_miller)
Date: Thu, 15 Oct 2020 17:36:32 +0000
Subject: [New-bugs-announce] [issue42046] Unable to write to file without
 elevated privileges
Message-ID: <1602783392.97.0.0712436068375.issue42046@roundup.psfhosted.org>


New submission from john_miller <johnson.b.ourne+pythonbugtracker at gmail.com>:

Trying to write into a file fails with a PermissionError (PermissionError: [Errno 13] Permission denied:).

Typing in a non-elevated shell (User is Administrator)
C:\Users\Username\Desktop>C:\Python38-32\python.exe
open("some_file.txt","w") fails on the Desktop, in the user directory and in directories where Administrators are permitted to write (while normal users can only read and execute).

(Permissions for the user in those directories: 
Desktop rwx, 
Username-directory rwx, 
third-location r-x for users/rwx for Administrator-user-group (with non-elevated applications))

I can write to all these places without elevation using the shell or standard applications like notepad.exe. 

Why do I have to elevate the Python-process to access such functionality? Is this related to the security-settings on python.exe or its installation-directory location?

Forcing a user to elevate the user-launched process for tasks that operate on normal user-writable files feels like a light security-risk. Because they get used to elevate Python-scripts even if the performed task by itself would not require it.

What changed compared to Python 2?

----------
components: Windows
messages: 378690
nosy: john_miller, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to write to file without elevated privileges
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 15 14:33:20 2020
From: report at bugs.python.org (David CARLIER)
Date: Thu, 15 Oct 2020 18:33:20 +0000
Subject: [New-bugs-announce] [issue42047] DragonFlyBSD thread native id
 support missing
Message-ID: <1602786800.77.0.034925025592.issue42047@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
components: Extension Modules
nosy: devnexen
priority: normal
severity: normal
status: open
title: DragonFlyBSD thread native id support missing
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 15 16:12:24 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 15 Oct 2020 20:12:24 +0000
Subject: [New-bugs-announce] [issue42048] Document Argument Clinic's
 defining_class converter
Message-ID: <1602792744.97.0.495560068875.issue42048@roundup.psfhosted.org>


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

The 'defining_class' AC converter is not documented.

https://www.python.org/dev/peps/pep-0573/#argument-clinic
https://docs.python.org/3.10/howto/clinic.html

----------
components: Argument Clinic
messages: 378696
nosy: erlendaasland, larry, vstinner
priority: normal
severity: normal
status: open
title: Document Argument Clinic's defining_class converter
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Oct 16 01:34:51 2020
From: report at bugs.python.org (waicalibre)
Date: Fri, 16 Oct 2020 05:34:51 +0000
Subject: [New-bugs-announce] [issue42049] Add image/webp to list of media
 types in mimetypes.py
Message-ID: <1602826491.72.0.784851705448.issue42049@roundup.psfhosted.org>


New submission from waicalibre <waicailbre_aayx at protonmail.com>:

WebP is an open image format that's existed for 10 years and is supported by most modern web browsers: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#WebP. It should be in the list of media types.

----------
messages: 378702
nosy: waicalibre
priority: normal
severity: normal
status: open
title: Add image/webp to list of media types in mimetypes.py
type: enhancement

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

From report at bugs.python.org  Fri Oct 16 04:27:23 2020
From: report at bugs.python.org (Hartmut Goebel)
Date: Fri, 16 Oct 2020 08:27:23 +0000
Subject: [New-bugs-announce] [issue42050] ensurepip fails if cwd contains
 illformed setup.cf
Message-ID: <1602836843.13.0.778924482006.issue42050@roundup.psfhosted.org>


New submission from Hartmut Goebel <h.goebel at crazy-compilers.com>:

If the current directory contains a ill-formed setup.cfg, setting up a virtual env fails, caused by ensurepip failing:

Expected behaviour:
running ensurepip should completely ignore the content of the current working directory.

How to reproduce:

$ rm -rf /tmp/v2
$ mkdir /tmp/v2
$ cd /tmp/v2
$ cat > setup.cfg <<EOF
> [options]
> setuptools_requires
> EOF
$ python3 -m venv /tmp/v2/_venv
Error: Command '['/tmp/v2/_venv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 2.
$ /tmp/v2/_venv/bin/python3 -Im ensurepip --upgrade --default-pip
Looking in links: /tmp/tmpimoh6tke
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Exception:
?
configparser.ParsingError: Source contains parsing errors: 'setup.cfg'
        [line  2]: 'setuptools_requires\n'


Environment:
Tested with both Python 3.8.2 and 3.7.6

----------
components: Library (Lib)
messages: 378706
nosy: htgoebel
priority: normal
severity: normal
status: open
title: ensurepip fails if cwd contains illformed setup.cf
type: crash
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Oct 16 04:32:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Oct 2020 08:32:10 +0000
Subject: [New-bugs-announce] [issue42051] plistlib inherits XML
 vulnerabilities: we should document them
Message-ID: <1602837130.12.0.103266772697.issue42051@roundup.psfhosted.org>


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

The XML documentation starts with a red warning:

"Warning: The XML modules are not secure against erroneous or maliciously constructed data. If you need to parse untrusted or unauthenticated data see the XML vulnerabilities and The defusedxml Package sections. "
https://docs.python.org/dev/library/xml.html

I suggest to add the same warning to the plistlib library which uses the XML parser internally to handle XML files.

----------
components: Library (Lib)
messages: 378707
nosy: vstinner
priority: normal
severity: normal
status: open
title: plistlib inherits XML vulnerabilities: we should document them
type: security
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 16 06:48:40 2020
From: report at bugs.python.org (conchylicultor)
Date: Fri, 16 Oct 2020 10:48:40 +0000
Subject: [New-bugs-announce] [issue42052] pathlib.Path should not call str()
 internally to allow inheritance
Message-ID: <1602845320.78.0.454867915032.issue42052@roundup.psfhosted.org>


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

I'm writing a subclass of `pathlib.Path` with custom `__fspath__`.

To prevent bad usages (users should use `os.fspath(path)` instead of `str(path)` to access the underlying path), I would like to overwrite `str`:


```
class MyPath(pathlib.PosixPath):

  def __fspath__(self) -> str:
    # Custom fspath

  def __str__(self) -> str:
    raise TypeError(
        f'Please do not use `str()` directly:'
        ' * For display: Use, f-string, `.format` or `repr`'
        ' * To access the path string: Use `os.fspath`, as per PEP 519'
    )

  def __format__(self, format_spec) -> str:
    return format(super().__str__(), format_spec)
```

However, this is breaking pathlib internal, as `str(self)` is used at many places. It would be nice if all internal `str()` calls where replaced by some `self._str()`.

I also think it would be more semantically correct if some of the `__str__` call where replaced by `__fspath__`, like: https://github.com/python/cpython/blob/b30934e9afb0af3f8e2e5f0992445be775b3c630/Lib/pathlib.py#L748

----------
components: Library (Lib)
messages: 378710
nosy: conchylicultor
priority: normal
severity: normal
status: open
title: pathlib.Path should not call str() internally to allow inheritance
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 16 13:31:45 2020
From: report at bugs.python.org (dubiousjim)
Date: Fri, 16 Oct 2020 17:31:45 +0000
Subject: [New-bugs-announce] [issue42053] fwalk: incorrect boolean test for
 non-fd arguments
Message-ID: <1602869505.61.0.789643368245.issue42053@roundup.psfhosted.org>


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

`Lib/os.py` has at line 464, in definition of `fwalk`:

```
if not isinstance(top, int) or not hasattr(top, '__index__'):
```

If I understand this test correctly, it should be requiring that the name/fd is NEITHER an int NOR has an __index__ method. As written, anything which fails the left-hand side (and so is an int) will probably have an __index__ method, so the right-hand side is idle.

Proposed fix: change `or` to `and`.

----------
components: Library (Lib)
messages: 378725
nosy: dubiousjim
priority: normal
severity: normal
status: open
title: fwalk: incorrect boolean test for non-fd arguments
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 16 15:24:02 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Fri, 16 Oct 2020 19:24:02 +0000
Subject: [New-bugs-announce] [issue42054] email message get_content throws
 KeyError for content main types font and model
Message-ID: <1602876242.42.0.187869890423.issue42054@roundup.psfhosted.org>


New submission from Mark Sapiro <mark at msapiro.net>:

With Policy = email.policy.default, there are handlers for get_content() only for content types 'text', 'audio', 'image', 'video', 'application', 'message/rfc822', 'message/external-body' and 'message'. While these are the only main types listed in RFC 6838, RFC 8081 adds 'font' and RFC 2077 defines 'model' there are several registered 'font' and 'model' types at https://www.iana.org/assignments/media-types/media-types.xhtml

It would be good if get_content() returned content, even if only raw bytes, for those types.

----------
messages: 378738
nosy: msapiro
priority: normal
severity: normal
status: open
title: email message get_content throws KeyError for content main types font and model
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/issue42054>
_______________________________________

From report at bugs.python.org  Fri Oct 16 16:15:31 2020
From: report at bugs.python.org (Matias Grioni)
Date: Fri, 16 Oct 2020 20:15:31 +0000
Subject: [New-bugs-announce] [issue42055] Python Nuget Packages for Windows
 Installation: Request for more versions
Message-ID: <1602879331.23.0.640725632242.issue42055@roundup.psfhosted.org>


New submission from Matias Grioni <matgrioni at gmail.com>:

Hello,

The python nuget feed here, https://www.nuget.org/packages/python, has a lot of the versions post 3.5. However, it is missing some bug fix and security fix versions. For example, it has no versions after 3.6.8, which had security fixes until 3.6.12.

Is there a specific reason for excluding these? I can't tell any pattern related to security or bug fix versions for each of the minor versions.

Thanks,

Matias

----------
components: Installation, Windows
messages: 378743
nosy: matgrioni, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python Nuget Packages for Windows Installation: Request for more versions
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct 16 18:47:17 2020
From: report at bugs.python.org (=?utf-8?q?Misty_De_M=C3=A9o?=)
Date: Fri, 16 Oct 2020 22:47:17 +0000
Subject: [New-bugs-announce] [issue42056] Configure on Apple ARM:
 "Unexpected output of 'arch' on OSX"
Message-ID: <1602888437.02.0.217887780449.issue42056@roundup.psfhosted.org>


New submission from Misty De M?o <mistydemeo at gmail.com>:

Configure's `arch` check on Macs running with Apple Silicon CPUs will fail because the list of acceptable architectures is hardcoded to Intel and PowerPC: https://github.com/python/cpython/blob/master/configure.ac#L2486-L2496

This needs a clause that adds "arm64" as an acceptable arch.

----------
components: Build
messages: 378776
nosy: mistydemeo
priority: normal
severity: normal
status: open
title: Configure on Apple ARM: "Unexpected output of 'arch' on OSX"
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 16 22:33:29 2020
From: report at bugs.python.org (Hiroshi Miura)
Date: Sat, 17 Oct 2020 02:33:29 +0000
Subject: [New-bugs-announce] [issue42057] pytest case which catch exceptions
 become segfault
Message-ID: <1602902009.62.0.945717377776.issue42057@roundup.psfhosted.org>


New submission from Hiroshi Miura <miurahr at linux.com>:

I've observed that pytest becomes segmentation fault on python 3.9.0 with attached case.

I've tested the case with several python versions;
  python 3.9.0a2 - good
  python 3.9.0a3, 3.9.0-final - bad
  python 3.10.0a1 - good

- OS: Mint Linux 20, Linux kernel 5.8.14
- Attachments:
    * test_main.py  - pytest test case to reproduce
    * py_stacktrace.txt - pytest result which become segmentation fault
    * gdb_backtrace.txt - gdb backtrace

So I've bisected and  a result is as follows;

9af0e47b1705457bb6b327c197f2ec5737a1d8f6 is the first bad commit
commit 9af0e47b1705457bb6b327c197f2ec5737a1d8f6
Author: Mark Shannon <mark at hotpy.org>
Date:   Tue Jan 14 10:12:45 2020 +0000

    bpo-39156: Break up COMPARE_OP into four logically distinct opcodes. (GH-17754)

    Break up COMPARE_OP into four logically distinct opcodes:
    * COMPARE_OP for rich comparisons
    * IS_OP for 'is' and 'is not' tests
    * CONTAINS_OP for 'in' and 'is not' tests
    * JUMP_IF_NOT_EXC_MATCH for checking exceptions in 'try-except' statements.

 Doc/library/dis.rst                                |   21 +
 Include/opcode.h                                   |    8 +-
 Lib/importlib/_bootstrap_external.py               |    3 +-
 Lib/opcode.py                                      |    7 +-
 Lib/test/test_dis.py                               |  141 +-
 Lib/test/test_peepholer.py                         |   12 +-
 Lib/test/test_positional_only_arg.py               |    6 +-
 .../2019-12-30-10-53-59.bpo-39156.veT-CB.rst       |    9 +
 PC/launcher.c                                      |    3 +-
 Python/ceval.c                                     |  137 +-
 Python/compile.c                                   |   71 +-
 Python/importlib.h                                 | 2922 +++++++------
 Python/importlib_external.h                        | 4560 ++++++++++----------
 Python/importlib_zipimport.h                       | 1831 ++++----
 Python/opcode_targets.h                            |    6 +-
 Python/peephole.c                                  |    6 +-
 Tools/scripts/generate_opcode_h.py                 |    5 -
 17 files changed, 4901 insertions(+), 4847 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2019-12-30-10-53-59.bpo-39156.veT-CB.rst

----------
components: Interpreter Core
files: test_main.py
messages: 378796
nosy: miurahr
priority: normal
severity: normal
status: open
title: pytest case which catch  exceptions become segfault
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49521/test_main.py

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

From report at bugs.python.org  Fri Oct 16 22:45:23 2020
From: report at bugs.python.org (Vaibhav Banait)
Date: Sat, 17 Oct 2020 02:45:23 +0000
Subject: [New-bugs-announce] [issue42058] Process not running with args
Message-ID: <1602902723.88.0.655306807418.issue42058@roundup.psfhosted.org>


New submission from Vaibhav Banait <vbanait at gmail.com>:

I am getting this error on windows 10 python 3.8 Emacs 27 and prelude configuration

Company: backend company-ngram-backend error "Process company-ngram not running" with args (prefix)

I am using this code in .emacs

    (with-eval-after-load 'company-ngram
  ; ~/data/ngram/*.txt are used as data
  (setq company-ngram-data-dir "~/data/ngram")
  ; company-ngram supports python 3 or newer
  (setq company-ngram-python "python3")
  (company-ngram-init)
  (cons 'company-ngram-backend company-backends)
  ; or use `M-x turn-on-company-ngram' and
  ; `M-x turn-off-company-ngram' on individual buffers
  ;
  ; save the cache of candidates
  (run-with-idle-timer 7200 t
                       (lambda ()
                         (company-ngram-command "save_cache")
                         ))
  )

(require 'company-ngram nil t)

----------
components: Regular Expressions
messages: 378797
nosy: ezio.melotti, mrabarnett, vbanait
priority: normal
severity: normal
status: open
title: Process not running with args
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 17 05:23:29 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 17 Oct 2020 09:23:29 +0000
Subject: [New-bugs-announce] [issue42059] TypedDict(...) as function does
 not respect "total" when setting __required_keys__ and __optional_keys__
Message-ID: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>


New submission from Alex Gr?nholm <alex.gronholm at nextday.fi>:

>>> DummyDict = TypedDict('DummyDict', {'x': int, 'y': str}, total=False)
>>> DummyDict.__required_keys__
frozenset({'x', 'y'})

This happens because the TypedDict function does not pass the "total" metaclass argument to _TypedDictMeta() (instead passing "__total__" in the attribute namespace) and the new code that sets __required_keys__ and __optional_keys__ only checks the metaclass argument.

----------
components: Library (Lib)
messages: 378805
nosy: alex.gronholm
priority: normal
severity: normal
status: open
title: TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 17 08:53:09 2020
From: report at bugs.python.org (Felipe Rodrigues)
Date: Sat, 17 Oct 2020 12:53:09 +0000
Subject: [New-bugs-announce] [issue42060] Usage of assert in http/client.py
Message-ID: <1602939189.16.0.999843550668.issue42060@roundup.psfhosted.org>


New submission from Felipe Rodrigues <felipe at felipevr.com>:

Hi all!

I was testing some static analysis tool and decided to use the HTTP module as testing ground. While running `bandit` at the client module, it detected 3 instances of using `assert` inside the code. Twice in the HTTPResponse class and once in the HTTPConnection class.

Now, I know that this will only cause any trouble when running python with the optimize settings turned on and if someone is that concerned about optimization, they probably won't be using the stdlib's HTTP implementation, but I think it would be fitting to fix this corner case.

I've written a PR that fixes this but I'm not sure if the raised exceptions and messages are ok

----------
components: Library (Lib)
messages: 378810
nosy: fbidu
priority: normal
severity: normal
status: open
title: Usage of assert in http/client.py
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 17 09:03:51 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 17 Oct 2020 13:03:51 +0000
Subject: [New-bugs-announce] [issue42061] Document __format__ method for
 IPv[46]Address
Message-ID: <1602939831.57.0.752623418103.issue42061@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

This feature was added in issue 32820, but was never documented.

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 378812
nosy: docs at python, eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Document __format__ method for IPv[46]Address
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Oct 17 10:13:56 2020
From: report at bugs.python.org (Felipe Rodrigues)
Date: Sat, 17 Oct 2020 14:13:56 +0000
Subject: [New-bugs-announce] [issue42062] Usage of HTTPResponse.url
Message-ID: <1602944036.34.0.151561478116.issue42062@roundup.psfhosted.org>


New submission from Felipe Rodrigues <felipe at felipevr.com>:

Hello all,

While testing some static analysis tools on HTTP/client.py, Pylint pointed
me to HTTPResponse.geturl() method with a "no-member" error for the `url`
attribute. I tried invoking the `geturl` method and reading the
`HTTPResponse.url` attribute using a sample code from the official docs:

```
import http.client
conn = http.client.HTTPSConnection("www.python.org")
conn.request("GET", "/")
r1 = conn.getresponse()
print(r1.status, r1.reason)

r1.geturl()
r1.url
```
```
import http.client
conn = http.client.HTTPSConnection("www.python.org")
conn.request("GET", "/")
r1 = conn.getresponse()
data1 = r1.read()

conn.request("GET", "/")
r1 = conn.getresponse()
while chunk := r1.read(200):
    print(repr(chunk))
r1.geturl()
r1.url
```

Both of those examples will raise an `AttributeError: 'HTTPResponse' object has no attribute 'url'`.

I tried searching through this module's history from when this line originally appeared,
https://github.com/python/cpython/commit/6c5e28c383bf587f80d01e52f887801be200200d but
I wasn't able to find this attribute being set internally by the class, even
though there is an `url` attribute at __init__.

So, I wonder if this attribute was intended to be set externally as in `r1.url = 'something'`
or if it is just a bug

----------
components: Library (Lib)
messages: 378814
nosy: fbidu
priority: normal
severity: normal
status: open
title: Usage of HTTPResponse.url

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

From report at bugs.python.org  Sat Oct 17 15:07:16 2020
From: report at bugs.python.org (Jake)
Date: Sat, 17 Oct 2020 19:07:16 +0000
Subject: [New-bugs-announce] [issue42063] More options to http.server &
 SimpleHTTPRequestHandler
Message-ID: <1602961636.81.0.0728597906503.issue42063@roundup.psfhosted.org>


New submission from Jake <sorme at kth.se>:

I would find it useful to have more options to http.server SimpleHTTPRequestHandler:

1) The option to get the current directory in not only HTML, but represented in JSON for example. This could be an added --json flag in the main method of http.server, and an added corresponding method in SimpleHTTPRequestHandler much like list_directory but for JSON. 


2) Options to add more headers. For example I would find it useful to be able to add the header 'Access-Control-Allow-Origin'. This could be achieved by send_head in SimpleHTTPRequestHandler taking more arguments for specifying any additional headers to be added. 

This way a custom class can inherit SimpleHTTPRequestHandler, and in its own send_head method call e.g. super().send_head(extra_headers={'Access-Control-Allow-Origin','*'}).

----------
components: Library (Lib)
messages: 378823
nosy: jacobsorme
priority: normal
severity: normal
status: open
title: More options to http.server & SimpleHTTPRequestHandler
type: enhancement

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

From report at bugs.python.org  Sat Oct 17 15:37:05 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 17 Oct 2020 19:37:05 +0000
Subject: [New-bugs-announce] [issue42064] Convert sqlite3 to multi-phase
 initialisation (PEP 489)
Message-ID: <1602963425.44.0.576962569847.issue42064@roundup.psfhosted.org>


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

Porting sqlite3 to multi-phase initialisation is non-trivial and must be broken into smaller bpo's, often with multiple PR's per bpo. As far as I can see, this is the task list:

1) Heap types (PEP 384): bpo-41861
2) Argument Clinic: bpo-40956
3) Establish global module state
4) Pass `self` iso. callback object to trace, auth, and progress handlers (required for item 7)
5) Use sqlite3_create_collation_v2 iso. sqlite3_create_collation (see next list item)
6) For sqlite3_create_* functions, establish a context struct that contains the target user callback and the state. Modify callers to allocate memory, and the destructor to deallocate
7) Module state (PEP 573)
8) Multi-phase initialisation (PEP 489)

The list may be incomplete.

Separate bpo's for 1) and 2) are opened. Pr. 2020-10-17, 1) is almost done, and 2), part 1 of 5 is awaiting review. It may be convenient to open up sub-bpo's for some of the other tasks as well. For instance, using sqlite3_create_collation_v2() iso. sqlite3_create_collation(). (FYI, this imposes no new SQLite version requirements.)

I'd wait until AC is implemented with moving forward with the rest of the PR's, in order to avoid merge mess. The exception might be item 4, preparing the trace/progress/auth callbacks, which is easy to isolate from the rest.

I've prepared branches for most of these things locally, some split in multiple PR's to ease reviewing.

I've tagged Victor Stinner and Dong-hee Na (hope that's ok), since they've been helpful with reviewing and providing helpful hints thus far. Any input from Berker Peksag would be highly appreciated; after all, he is the maintainer of this module :)

Ref. bpo-1635741 (the grand multi-phase issue)

----------
components: Library (Lib)
messages: 378825
nosy: berker.peksag, corona10, erlendaasland, vstinner
priority: normal
severity: normal
status: open
title: Convert sqlite3 to multi-phase initialisation (PEP 489)
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 17 16:05:08 2020
From: report at bugs.python.org (Tal Einat)
Date: Sat, 17 Oct 2020 20:05:08 +0000
Subject: [New-bugs-announce] [issue42065] Fix incorrectly formatted
 _codecs.charmap_decode error message
Message-ID: <1602965108.98.0.722974921612.issue42065@roundup.psfhosted.org>


New submission from Tal Einat <taleinat+python at gmail.com>:

The error message for _codecs.charmap_decode uses a non-existent formatting placeholder "%lx", when a mapped value is a number outside the range of valid Unicode code points.

This was reported by Max Bernstein (@tekknolagi) on GitHub PR GH-19940.

----------
messages: 378827
nosy: taleinat
priority: normal
severity: normal
status: open
title: Fix incorrectly formatted _codecs.charmap_decode error message

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

From report at bugs.python.org  Sun Oct 18 04:59:25 2020
From: report at bugs.python.org (Iman Kermani)
Date: Sun, 18 Oct 2020 08:59:25 +0000
Subject: [New-bugs-announce] [issue42066] CookieJar cookies should not be
 sorted
Message-ID: <1603011565.07.0.705714624719.issue42066@roundup.psfhosted.org>


New submission from Iman Kermani <imankermani at hotmail.com>:

Lib/http/cookiejar.py

By default python handle cookies based on regular Netscape cookie protocol and the protocol defined by RFC 2965.

There is a behavior in python which sort cookies in CookieJar by default:
https://github.com/python/cpython/blob/975d10a4f8f5d99b01d02fc5f99305a86827f28e/Lib/http/cookiejar.py#L1220

Moreover there is no definition in the 2965 about the cookie ordering in Cookie Header when cookies have equal-length path fields.

This is a undesirable behavior when working with certain libraries like requests. https://github.com/psf/requests/issues/5630
 
In this case browser implements the RFC 6265 which obsoletes the RFC 2965. Therefore The behavior is based on https://tools.ietf.org/html/rfc6265#section-5.4:
"The user agent SHOULD sort the cookie-list in the following order:
Cookies with longer paths are listed before cookies with shorter paths.
Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times."

This means that the order of the cookies with same path attribute in Cookie header follow the Set-Cookie order in the HTTP response.

RFC 6265 compliance is not what this issue is meant rather it imply on the sorting of cookies which is unnecessary here and not mentioned in RFC 2965 or the regular Netscape cookie protocol.

Thanks in advance for looking into this issue

Regards.

----------
components: Library (Lib)
messages: 378855
nosy: IKermani
priority: normal
severity: normal
status: open
title: CookieJar cookies should not be sorted
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/issue42066>
_______________________________________

From report at bugs.python.org  Sun Oct 18 08:57:26 2020
From: report at bugs.python.org (barak dopama)
Date: Sun, 18 Oct 2020 12:57:26 +0000
Subject: [New-bugs-announce] [issue42067] Type annotation in for-loops
Message-ID: <1603025846.26.0.322544281802.issue42067@roundup.psfhosted.org>


New submission from barak dopama <gaaartner at gmail.com>:

Why do I have to do this:
        for element in my_list:
            element: ElementType = element
            process(element)
And can't do this:
        for element: ElementType  in my_list:
            process(element)

----------
components: Build
messages: 378859
nosy: gaaartner
priority: normal
severity: normal
status: open
title: Type annotation in for-loops
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 18 09:20:59 2020
From: report at bugs.python.org (Marc Culler)
Date: Sun, 18 Oct 2020 13:20:59 +0000
Subject: [New-bugs-announce] [issue42068] For macOS,
 package the included Tcl and Tk frameworks in a rational way.
Message-ID: <1603027259.23.0.956934315272.issue42068@roundup.psfhosted.org>


New submission from Marc Culler <marc.culler at gmail.com>:

Packaging Tcl and Tk within the python framework is a great idea
and a big improvement.  But the way it is being done is pretty crazy,
and makes it unnecessarily difficult to upgrade the version of Tcl/Tk
that python is using.  That is something which should be easy,
especially since python is still using version 8.6.8 even though 8.6.11
is about to be released and includes the results of a huge effort to
improve and stabilize the macOS port of Tk.

There is a standard and completely straightforward way of including
a framework within a framework.  The normal thing to do would be
to create a directory Python.framework/Versions/X.Y/Frameworks/ which
contains Tcl.framework and Tk.framework.  Upgrading to a newer version
of Tcl and Tk would then simply require updating those frameworks, which
would be very easy to accomplish, for example, with a .pkg file.

Instead of doing this, Python currently jams everything related to Tcl
and Tk into its lib directory, changing the library and directory names
randomly and breaking the standard directory structure that Tcl and Tk
use in their frameworks.

Why not make it standard and simple?  Why add all of this random noise?

----------
components: macOS
messages: 378860
nosy: culler, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: For macOS, package the included Tcl and Tk frameworks in a rational way.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 18 12:54:54 2020
From: report at bugs.python.org (Alex)
Date: Sun, 18 Oct 2020 16:54:54 +0000
Subject: [New-bugs-announce] [issue42069] Make filecmp more pythonic
Message-ID: <1603040094.49.0.136787075744.issue42069@roundup.psfhosted.org>


New submission from Alex <br.shurik at gmail.com>:

Cleanup the filecmp file add typing and make it more pythonic

----------
components: Library (Lib)
messages: 378877
nosy: alex.briskin
priority: normal
severity: normal
status: open
title: Make filecmp more pythonic
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 18 14:44:55 2020
From: report at bugs.python.org (Msimpasona)
Date: Sun, 18 Oct 2020 18:44:55 +0000
Subject: [New-bugs-announce] [issue42070] I think the rationale to keep
 IsoCalendarDate private from the pickle perspective should get revisited
Message-ID: <1603046695.09.0.570659045382.issue42070@roundup.psfhosted.org>


New submission from Msimpasona <msimpasona at gmail.com>:

IsoCalendarDate is pickled as a regular tuple and so requires a slightly different code flow in case the pickle file is used as cache. More details here: https://stackoverflow.com/questions/64408303/python-3-9-unpickling-of-isocalendardate-data-returns-a-tuple

My question is what's the benefit of hiding the new class IsoCalendarDate?

----------
components: Library (Lib)
messages: 378884
nosy: msimpasona
priority: normal
severity: normal
status: open
title: I think the rationale to keep IsoCalendarDate private from the pickle perspective should get revisited
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 18 14:58:45 2020
From: report at bugs.python.org (Marco Castelluccio)
Date: Sun, 18 Oct 2020 18:58:45 +0000
Subject: [New-bugs-announce] [issue42071] Shelve should default to the
 default Pickle protocol instead of hardcoding version 3
Message-ID: <1603047525.23.0.754911707422.issue42071@roundup.psfhosted.org>


New submission from Marco Castelluccio <mcastelluccio at mozilla.com>:

Shelve is currently defaulting to Pickle protocol 3, instead of using Pickle's default protocol for the Python version in use.

This way, Shelve's users don't benefit from improvements introduced in newer Pickle protocols, unless they notice it and manually pass a newer protocol version to shelve.open or the Shelf constructor.

----------
components: Library (Lib)
messages: 378885
nosy: marco-c
priority: normal
severity: normal
status: open
title: Shelve should default to the default Pickle protocol instead of hardcoding version 3
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/issue42071>
_______________________________________

From report at bugs.python.org  Sun Oct 18 16:19:04 2020
From: report at bugs.python.org (Grisha Lukovnikov)
Date: Sun, 18 Oct 2020 20:19:04 +0000
Subject: [New-bugs-announce] [issue42072] requests
Message-ID: <1603052344.71.0.153808857129.issue42072@roundup.psfhosted.org>


New submission from Grisha Lukovnikov <grishalukovnikov97 at gmail.com>:

Traceback (most recent call last):
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 670, in urlopen
    httplib_response = self._make_request(
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 381, in _make_request
    self._validate_conn(conn)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 978, in _validate_conn
    conn.connect()
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connection.py", line 343, in connect
    self.ssl_context = create_urllib3_context(
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\util\ssl_.py", line 301, in create_urllib3_context
    context.keylog_filename = os.environ.get("SSLKEYLOGFILE")
PermissionError: [Errno 13] Permission denied: 'C:\\Users\\dns\\Desktop'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\adapters.py", line 439, in send
    resp = conn.urlopen(
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 726, in urlopen
    retries = retries.increment(
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\util\retry.py", line 403, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\packages\six.py", line 734, in reraise
    raise value.with_traceback(tb)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 670, in urlopen
    httplib_response = self._make_request(
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 381, in _make_request
    self._validate_conn(conn)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 978, in _validate_conn
    conn.connect()
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connection.py", line 343, in connect
    self.ssl_context = create_urllib3_context(
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\util\ssl_.py", line 301, in create_urllib3_context
    context.keylog_filename = os.environ.get("SSLKEYLOGFILE")
urllib3.exceptions.ProtocolError: ('Connection aborted.', PermissionError(13, 'Permission denied'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\dns\Desktop\kurs.py", line 3, in <module>
    print(requests.get("https://yandex.ru", verify=False).content)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\api.py", line 76, in get
    return request('get', url, params=params, **kwargs)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\api.py", line 61, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\sessions.py", line 530, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\sessions.py", line 643, in send
    r = adapter.send(request, **kwargs)
  File "C:\Users\dns\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\adapters.py", line 498, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', PermissionError(13, 'Permission denied'))

----------
components: Windows
files: kurs.py
messages: 378892
nosy: grishalukovnikov97, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: requests
versions: Python 3.9
Added file: https://bugs.python.org/file49524/kurs.py

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

From report at bugs.python.org  Sun Oct 18 16:22:44 2020
From: report at bugs.python.org (Erik Welch)
Date: Sun, 18 Oct 2020 20:22:44 +0000
Subject: [New-bugs-announce] [issue42073] classmethod does not pass
 "type/owner" when invoking wrapped __get__
Message-ID: <1603052564.81.0.969263752847.issue42073@roundup.psfhosted.org>


New submission from Erik Welch <erik.n.welch at gmail.com>:

The following is new to Python 3.9, and I consider the implementation incomplete.  I have code that works for Python 3.8 and before, but not for Python 3.9:

"Class methods can now wrap other :term:`descriptors <descriptor>` such as :func:`property`."

https://github.com/python/cpython/pull/8405
https://bugs.python.org/issue19072

As implemented, `classmethod` does not correctly wrap descriptors that mimic classmethod.  Previously, __get__of wrapped objects wasn't invoked by classmethod, so it was safe to have an object with both __call__ and __get__ behave like a classmethod.  Now, classmethod calling __get__ first gives incorrect results.

Here is a minimal example:
```
from types import MethodType


class myclassmethod:
    def __init__(self, func):
        self.func = func

    def __call__(self, cls):
        return self.func(cls)

    def __get__(self, instance, owner=None):
        if owner is None:
            owner = type(instance)
        return MethodType(self, owner)


class A:
    @myclassmethod
    def f1(cls):
        return cls

    @classmethod
    @myclassmethod
    def f2(cls):
        return cls


assert A.f1() is A
assert A.f2() is A  # <-- fails in 3.9, works in 3.8 and before
```
This pattern would typically be used to do something extra in __call__.

For the sake of discussion, let's call the two arguments to __get__ "instance" and "owner".  Typically, "instance" is an instance of "owner", or, equivalently, "owner" is the type of "instance".  If "owner" is None, it is generally assumed to be the type of "instance".

In bpo19072 (and gh8405), classmethod was changed to call `obj.__get__(owner)` if the wrapped object "obj" has __get__.  Notice that only the "instance" argument is provided.  Moreover, the type `owner` is passed as the "instance" argument.  This means that the "owner" argument (which is None) will be assumed to be the type of the "instance" argument, which is the type of the `owner` type.  This is wrong.  The "owner" argument should be `owner`.

I believe it would be better for classmethod to call `obj.__get__(owner, owner)` if "obj" has __get__.

This is kind of difficult to explain.  I will make a PR with more informative tests shortly.  Here is the simple diff to make the above example pass:
```
diff --git a/Objects/funcobject.c b/Objects/funcobject.c
index bd24f67b97..74f9167566 100644
--- a/Objects/funcobject.c
+++ b/Objects/funcobject.c
@@ -739,7 +739,7 @@ cm_descr_get(PyObject *self, PyObject *obj, PyObject *type)
         type = (PyObject *)(Py_TYPE(obj));
     if (Py_TYPE(cm->cm_callable)->tp_descr_get != NULL) {
         return Py_TYPE(cm->cm_callable)->tp_descr_get(cm->cm_callable, type,
-                                                      NULL);
+                                                      type);
     }
     return PyMethod_New(cm->cm_callable, type);
 }

```
Since I consider the new behavior to have introduced a regression, I think this change should be applied to both 3.9 and 3.10.

Cheers!

----------
components: Interpreter Core
messages: 378893
nosy: berker.peksag, eriknw, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: classmethod does not pass "type/owner" when invoking wrapped __get__
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sun Oct 18 17:49:09 2020
From: report at bugs.python.org (CaptainMitsumoto)
Date: Sun, 18 Oct 2020 21:49:09 +0000
Subject: [New-bugs-announce] [issue42074] f***ing setup failed is driving me
 insane
Message-ID: <1603057749.44.0.277772505127.issue42074@roundup.psfhosted.org>


New submission from CaptainMitsumoto <rikkuguzai at gmail.com>:

I am frustrated now. I was about to install Python 3.9.0 in my gaming laptop then I get this thing.

I tried to google the hex error and the error name. I tried getting help in Python Discord but no good luck, they're weren't any good solutions. I got this bug yesterday and I waited 1 day later (which is today) and it still existed. I tried installing the old versions before Python 3.9.0, still nope. Wow, this crap is driving me crazy, all I wanted to do is to code in Python.

Error: 0x80070002 - The system cannot find the file specified.

----------
components: Unicode
files: dsafdsfdsfdsfdsfsafsafsadfsagggg.PNG
messages: 378904
nosy: ezio.melotti, rikkuguzai, vstinner
priority: normal
severity: normal
status: open
title: f***ing setup failed is driving me insane
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49525/dsafdsfdsfdsfdsfsafsafsadfsagggg.PNG

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

From report at bugs.python.org  Sun Oct 18 18:15:40 2020
From: report at bugs.python.org (Mithil)
Date: Sun, 18 Oct 2020 22:15:40 +0000
Subject: [New-bugs-announce] [issue42075] Verbose/confusing default format
 on warnings
Message-ID: <1603059340.5.0.993614197366.issue42075@roundup.psfhosted.org>


New submission from Mithil <mithil467 at gmail.com>:

The default format prints a lot of details like filename, line number, and the source code on that line. A particular case where the warn message is written on the next line like -
warn(
   "Message here")
Will only print warn( as the source code and not the entire block.
My concern is, can this formatting be less detailed by default. Or, can this format be freely changed in a project A without worrying about affecting the global usage in any other project B that imports it.
Or at the very least, can this be made to print the entire block of code and not just the one line, because that makes it very confusing for the user.

More takes on the issue here - https://github.com/PyCQA/isort/issues/1568

----------
components: Library (Lib)
messages: 378906
nosy: Mithil
priority: normal
severity: normal
status: open
title: Verbose/confusing default format on warnings
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/issue42075>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:00:52 2020
From: report at bugs.python.org (Serhiy Ivanov)
Date: Sun, 18 Oct 2020 23:00:52 +0000
Subject: [New-bugs-announce] [issue42076] urllib ResourceWarning in case of
 usage of FTP
Message-ID: <1603062052.42.0.758014022395.issue42076@roundup.psfhosted.org>


New submission from Serhiy Ivanov <icegood1980 at gmail.com>:

In case when FTP url is successfully connected via default FTPHandler in FTPHandler.connect_ftp then release of this stuff becomes total responsibility of user i.e. socket remains open, which leads to ResourceWarning in the garbage collector, in case if the user does nothing.

Something like this solves issue in user area:

class SafeFTPHandler(urllib.request.FTPHandler):
          ftp_object = None

          def __init__(self):
            super().__init__()

          def connect_ftp(self, user, passwd, host, port, dirs, timeout):
              self.ftp_object = super().connect_ftp(user, passwd, host, port, dirs, timeout)
              return self.ftp_object

          def ftp_response(self, req, response):
              self._close_ftp()
              return response

          def ftp_open(self, req):
            try:
              return super().ftp_open(req)
            except:
              self._close_ftp()
              raise

          def _close_ftp(self):
            if self.ftp_object:
                self.ftp_object.close()

and further usage in OpenerDirector...

In general case FTPHandler should be able to close immediately (in case if it raises as well) while re-using of the socket should be implemented only within CacheFTPHandler

----------
components: Library (Lib)
messages: 378911
nosy: icegood
priority: normal
severity: normal
status: open
title: urllib ResourceWarning in case of usage of FTP
type: resource usage
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 18 22:18:56 2020
From: report at bugs.python.org (Zheng SHAO)
Date: Mon, 19 Oct 2020 02:18:56 +0000
Subject: [New-bugs-announce] [issue42077] Some Absolute domain name not work
 in urllib
Message-ID: <1603073936.71.0.541010072663.issue42077@roundup.psfhosted.org>


New submission from Zheng SHAO <axot at msn.com>:

```
import ssl
import urllib.request

url_string = "https://kubernetes.default.svc.cluster.local./api/"

ctx = ssl._create_unverified_context()

with urllib.request.urlopen(url_string, context=ctx) as f:
    f.read()
```

In running this sample code will got a following handshake error,

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.8/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/lib/python3.8/urllib/request.py", line 542, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File "/usr/lib/python3.8/urllib/request.py", line 502, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 1393, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File "/usr/lib/python3.8/urllib/request.py", line 1353, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: SSLV3_ALERT_UNEXPECTED_MESSAGE] sslv3 alert unexpected message (_ssl.c:1123)>

Instead using absolute domain name, using `https://kubernetes.default.svc.cluster.local/api/` then the issue solved. I also tried other domains like `google.com.`, but in this case the handshake process had no errors.

----------
components: Library (Lib)
messages: 378919
nosy: axot
priority: normal
severity: normal
status: open
title: Some Absolute domain name not work in urllib
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 19 03:03:42 2020
From: report at bugs.python.org (Gisle Vanem)
Date: Mon, 19 Oct 2020 07:03:42 +0000
Subject: [New-bugs-announce] [issue42078] _tracemalloc.c and Clang-cl
Message-ID: <1603091022.29.0.567599284376.issue42078@roundup.psfhosted.org>


New submission from Gisle Vanem <gvanem at yahoo.no>:

Related to:
  https://bugs.python.org/issue33351

where I commented above the following. 
When using `clang-cl` to build, I get the following error:
```
Modules/_tracemalloc.c(55,9): error: declaration of anonymous struct must be a definition
typedef struct
        ^
Modules/_tracemalloc.c(55,1): warning: typedef requires a name [-Wmissing-declarations]
typedef struct
^~~~~~~
Modules/_tracemalloc.c(68,9): warning: #pragma pack(pop, ...) failed: stack empty [-Wignored-pragmas]
#pragma pack(pop)
        ^
Modules/_tracemalloc.c(78,5): error: unknown type name 'frame_t'
    frame_t frames[1];
    ^
Modules/_tracemalloc.c(87,103): error: use of undeclared identifier 'frame_t'
static const unsigned long MAX_NFRAME = Py_MIN(UINT16_MAX, ((SIZE_MAX - sizeof(traceback_t)) / sizeof(frame_t) + 1));
                                                                                                      ^
Modules/_tracemalloc.c(87,103): error: use of undeclared identifier 'frame_t'
Modules/_tracemalloc.c(286,15): error: unknown type name 'frame_t'; did you mean 'trace_t'?
        const frame_t *frame1 = &traceback1->frames[i];
              ^~~~~~~
              trace_t
Modules/_tracemalloc.c(100,3): note: 'trace_t' declared here
} trace_t;
  ^
```

An easy fix is to patch it:
```
--- a/_tracemalloc.c 2020-10-18 12:06:55
+++ b/_tracemalloc.c 2020-10-19 09:02:17
@@ -52,11 +52,11 @@

 /* Pack the frame_t structure to reduce the memory footprint on 64-bit
    architectures: 12 bytes instead of 16. */
-typedef struct
 #ifdef __GNUC__
-__attribute__((packed))
+typedef struct __attribute__((packed))
 #elif defined(_MSC_VER)
 #pragma pack(push, 4)
+typedef struct
 #endif
 {
     /* filename cannot be NULL: "<unknown>" is used if the Python frame
```

(I'm amazed it's not done before).

----------
components: Build
messages: 378928
nosy: gvanem
priority: normal
severity: normal
status: open
title: _tracemalloc.c and Clang-cl
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 04:55:37 2020
From: report at bugs.python.org (Jan Schatz)
Date: Mon, 19 Oct 2020 08:55:37 +0000
Subject: [New-bugs-announce] [issue42079] Why does tarfile.next swallow
 InvalidHeaderError
Message-ID: <1603097737.92.0.915813500773.issue42079@roundup.psfhosted.org>


New submission from Jan Schatz <jan.schatz at hms-networks.com>:

I have a tar gz archive that fails to be extracted via tarfile.extractall(). By adding some debug code I found that at some point InvalidHeaderError is raised inside tarfile.next(). But the function just swallows the exception, because the offset isn't 0 (see https://github.com/python/cpython/blob/5368c2b6e23660cbce7e38dc68f859c66ac349ee/Lib/tarfile.py#L2334). Why does the function behave like this? I would expect an except rather than silently stopping extraction if the archive is damaged.

----------
components: Library (Lib)
messages: 378934
nosy: jan.schatz
priority: normal
severity: normal
status: open
title: Why does tarfile.next swallow InvalidHeaderError
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct 19 12:04:08 2020
From: report at bugs.python.org (John Ehresman)
Date: Mon, 19 Oct 2020 16:04:08 +0000
Subject: [New-bugs-announce] [issue42080] Disutils on windows debug build
 fails without -j1
Message-ID: <1603123448.09.0.581591280585.issue42080@roundup.psfhosted.org>


New submission from John Ehresman <jpe at wingware.com>:

Compiling pillow for a debug build fails without -j1 because distutils parallelizes the build, but there are problems with locking the .pdb file during when compiling the C files.  An example of the error message from a cl.exe command is:

fatal error C1041: cannot open program database 'C:\src\tmp\pillow-test\Pillow-7.2.0\vc140.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS

Building works with setup.py build_ext --disable-jpeg --disable-tiff --disable-zlib --debug build -j1

My guess is the fix is not to parallelize by default in a debug build; a /FS arg to cl.exe could be used, but that doesn't seem to be recommended.

I realize this might be considered a pillow bug, but my guess is that it affects other packages as well

----------
components: Distutils, Windows
messages: 378959
nosy: dstufft, eric.araujo, jpe, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Disutils on windows debug build fails without -j1
type: compile error
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 19 12:56:46 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2020 16:56:46 +0000
Subject: [New-bugs-announce] [issue42081] Consider fast_double_parser for
 faster str->double
Message-ID: <1603126606.04.0.157687249306.issue42081@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is more of a "could be nice" entry if there are any interested core developers.

A new algorithm and library was recently published for faster parsing of double numbers.  It claims rigorous accuracy and the performance is impressive.  The implementation is in C++ but it's really decorated C.  It also seems simple enough that it can be reimplemented independently.

https://github.com/lemire/fast_double_parser/

----------
components: Interpreter Core
messages: 378960
nosy: mark.dickinson, pitrou, tim.peters
priority: low
severity: normal
status: open
title: Consider fast_double_parser for faster str->double
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 13:27:28 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Oct 2020 17:27:28 +0000
Subject: [New-bugs-announce] [issue42082] Eliminate test_peg_generator
 redundant output
Message-ID: <1603128448.05.0.786885656714.issue42082@roundup.psfhosted.org>


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

When running tests locally (Win10), test_peg_generator outputs the following 20 times.

parse.c
pegen.c
string_parser.c
tokenizer.c
Python-ast.c
asdl.c
peg_extension.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmpcr6_pvyl\Debug\Users\Terry\AppData\Local\Temp\tmpcr6_pvyl\parse_d.cp310-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmpcr6_pvyl\Debug\Users\Terry\AppData\Local\Temp\tmpcr6_pvyl\parse_d.cp310-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance

Can this be fixed?

----------
components: Interpreter Core, Tests
messages: 378970
nosy: pablogsal, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate test_peg_generator redundant output
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 14:27:05 2020
From: report at bugs.python.org (Xemistry GmbH)
Date: Mon, 19 Oct 2020 18:27:05 +0000
Subject: [New-bugs-announce] [issue42083] PyStructSequence_NewType broken in
 3.8
Message-ID: <1603132025.42.0.432168177789.issue42083@roundup.psfhosted.org>


New submission from Xemistry GmbH <wdi at xemistry.com>:

Calling PyStructSequence_NewType() with a NULL field in the desc.doc parameter (explicitly allowed as per docs) leads to a crash in 

Objects/typeobject.c:2956
2956                size_t len = strlen(old_doc)+1;

where old_doc is NULL.
If the doc string is set, the call succeeds, but with a warning

(stdin):1: DeprecationWarning: builtin type G_SGROUP has no __module__ attribute

(where G_SGROUP is my new type), which did not happen in 3.6, and which I do not think can be suppressed by function call arguments.

----------
components: C API
messages: 378978
nosy: wdi2
priority: normal
severity: normal
status: open
title: PyStructSequence_NewType broken in 3.8
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 19 14:28:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Oct 2020 18:28:46 +0000
Subject: [New-bugs-announce] [issue42084] Language aware diff headers
Message-ID: <1603132126.97.0.165979992409.issue42084@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Improve our development environment by making the diff headers language aware.

See:  https://tekin.co.uk/2020/10/better-git-diff-output-for-ruby-python-elixir-and-more

----------
components: Build
messages: 378980
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Language aware diff headers
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 15:38:16 2020
From: report at bugs.python.org (Vladimir Matveev)
Date: Mon, 19 Oct 2020 19:38:16 +0000
Subject: [New-bugs-announce] [issue42085] Add dedicated slot for sending
 values
Message-ID: <1603136296.98.0.312180912341.issue42085@roundup.psfhosted.org>


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

https://bugs.python.org/issue41756 has introduced PyIter_Send as a common entrypoint for sending values however currently fast path that does not use StopIteration exception is only available for generators/coroutines. It would be quite nice if this machinery was extensible and other types (both internal and 3rd party) could opt-in into using exception-free way of returning values without needing to update the implementation of PyIter_Send. One way of solving this is adding a new slot with a signature that matches PyIter_Send. With it:
- it should be possible to implement this slot for coroutines/generators and remove  special casing for them  in PyIter_Send
- provide implementation for this slot for internal types (i.e. FutureIter in _asynciomodule.c) - results of this experiment can be found below
- enable external native extensions to provide efficient implementation of coroutines (i.e.  Cython could benefit from it)

Microbenchmark to demonstrate the difference of accessing the value of fulfiled Future without and with dedicated slot:
```
import asyncio
import time

N = 100000000

async def run():
    fut = asyncio.Future()
    fut.set_result(42)

    t0 = time.time()
    for _ in range(N):
        await fut
    t1 = time.time()
    print(f"Time: {t1 - t0} s")

asyncio.run(run())
```
Time: 8.365560054779053 s - without the slot
Time: 5.799655914306641 s - with the  slot

----------
components: Interpreter Core
messages: 378999
nosy: v2m
priority: normal
severity: normal
status: open
title: Add dedicated slot for sending values
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 15:58:22 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 19 Oct 2020 19:58:22 +0000
Subject: [New-bugs-announce] [issue42086] AST: Document / re-design? the
 simple constructor nodes from sums
Message-ID: <1603137502.35.0.449039325711.issue42086@roundup.psfhosted.org>


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

Simple constructors (basically constructors with no fields) are currently 'cached' / pre-created and dispatched. What I mean by that is, when a user parses some code with `ast.parse()` and gets a tree object, all simple constructors with the same value would point to the same object.

>>> mod1 = ast.parse("a + b", mode="eval")
>>> mod1.body.left.ctx
<ast.Load object at 0x7f8695321d20>
>>> mod1.body.right.ctx
<ast.Load object at 0x7f8695321d20>
>>> mod1.body.left.ctx is mod1.body.right.ctx
True
>>> mod1.body.left.ctx.some_annotation_that_my_extra_process_tool_puts = 1
>>> mod1.body.right.ctx.some_annotation_that_my_extra_process_tool_puts
1

Even though I have no real evidence that, this was done on purpose, I believe this is some sort of 'enum' replication (caching singletons but not really, since this is only valid for the results of ast.parse)
>>> mod1.body.right.ctx is ast.Load()
False
>>> ast.parse("a + b", mode="eval").body.left.ctx is ast.parse("c + d", mode="eval").body.right.ctx
True



Obviously, we can not change these into enums like (ast.expr_ctx.Load / LOAD) since it would break theoretically most of the code that works with ast. So here is a tl;dr:

- Even though all ast objects are mutable (by default), we use the same objects when converting C AST into Python AST. So that mutations on one object is affecting the rest of the tree. 

- We can either;
  - Document this behavior and keep it
  - Return freshly constructed objects when converting C AST into Python AST
    This has a very slight (that I suspect no body uses) risk of breaking code, but as I implied, very slight. Which would occur in such a case

import ast
from collections import defaultdict

def collect_contexts(tree):
    contexts = defaultdict(list)
    for node in ast.walk(tree):
        if isinstance(node, ast.Name):
            contexts[node.ctx].append(node.id)
    return contexts
    
print(collect_contexts(ast.parse("a, b = c, d")))

This code can easily (and it makes it more reliable/robust) refactored into 
-             contexts[node.ctx].append(node.id)
-             contexts[type(node.ctx)].append(node.id)
but just mentioning in case of any question appears about backwards incompatability.

----------
components: Library (Lib)
messages: 379004
nosy: BTaskaya, lys.nikolaou, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: AST: Document / re-design? the simple constructor nodes from sums
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 16:24:45 2020
From: report at bugs.python.org (Kevin)
Date: Mon, 19 Oct 2020 20:24:45 +0000
Subject: [New-bugs-announce] [issue42087] Remove pre-AIX 6.1 dead code paths
Message-ID: <1603139085.09.0.736153857755.issue42087@roundup.psfhosted.org>


New submission from Kevin <kadler at us.ibm.com>:

Follow on to https://bugs.python.org/issue40680. In there, it was decided that since AIX 5 and below doesn't support thread_cputime, support for it would be dropped and the issue was closed without removing any of the dead code paths and references.

----------
components: Interpreter Core
messages: 379007
nosy: kadler
priority: normal
severity: normal
status: open
title: Remove pre-AIX 6.1 dead code paths

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

From report at bugs.python.org  Mon Oct 19 16:34:54 2020
From: report at bugs.python.org (Ben Avrahami)
Date: Mon, 19 Oct 2020 20:34:54 +0000
Subject: [New-bugs-announce] [issue42088] types.SimpleNamespace.__repr__
 documentation inconsistency
Message-ID: <1603139694.62.0.339590504513.issue42088@roundup.psfhosted.org>


New submission from Ben Avrahami <avrahami.ben at gmail.com>:

According to the documentation for types.SimpleNamespace, `repr(SimpleNamespace())` should return `"SimpleNamespace()"`, but in actuality returns `"namespace()"`. This is because SimpleNamespace is an alias for the C implemented type `_PyNamespaceObject`. Interestingly, `_PyNamespaceObject` names itself `"types.SimpleNamespace"`. This has the obvious issue of the documentation being wrong, but also the (perhaps less interesting issue) of `eval(repr(SimpleNamespace))` resulting in a NameError.

I propose that `_PyNamespaceObject`'s __repr__ method be changed to return `"SimpleNamespace(<args>)"`. This would require only the change of a constant in one line (currently this is line 75 on namespaceobject.c).

A smaller fix would be to change the documentation to correctly reflect this behavior.

----------
components: Library (Lib)
messages: 379010
nosy: avrahami.ben
priority: normal
severity: normal
status: open
title: types.SimpleNamespace.__repr__ documentation inconsistency
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 16:50:51 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 19 Oct 2020 20:50:51 +0000
Subject: [New-bugs-announce] [issue42089] Better message in
 PackageNotFoundError
Message-ID: <1603140651.15.0.510180378799.issue42089@roundup.psfhosted.org>


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

As reported in https://gitlab.com/python-devs/importlib_metadata/-/issues/124, it would be nice if the PackageNotFoundError gave some guidance to the user about the context of the error and how to investigate.

----------
assignee: jaraco
components: Library (Lib)
messages: 379015
nosy: jaraco
priority: normal
severity: normal
status: open
title: Better message in PackageNotFoundError
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 16:58:28 2020
From: report at bugs.python.org (conchylicultor)
Date: Mon, 19 Oct 2020 20:58:28 +0000
Subject: [New-bugs-announce] [issue42090] zipfile.Path.joinpath API
 inconsistent with pathlib.Path.joinpath
Message-ID: <1603141108.13.0.969027124293.issue42090@roundup.psfhosted.org>


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

The following code fail with zipfile.Path, but works with pathlib.Path:

```
path = path.joinpath().joinpath('other', 'other')
```

Zipfile: https://github.com/python/cpython/blob/95ad890a7b0341d8d2fde13f824bc24c65a8ece0/Lib/zipfile.py#L2363

```
def joinpath(self, add):
```

Pathlib: https://github.com/python/cpython/blob/95ad890a7b0341d8d2fde13f824bc24c65a8ece0/Lib/pathlib.py#L955

```
def joinpath(self, *args):
```

----------
components: Library (Lib)
messages: 379016
nosy: conchylicultor
priority: normal
severity: normal
status: open
title: zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 19 17:07:11 2020
From: report at bugs.python.org (Pridhvi Myneni)
Date: Mon, 19 Oct 2020 21:07:11 +0000
Subject: [New-bugs-announce] [issue42091] strftime returns empty string for
 -d, -I 3.8.3
Message-ID: <1603141631.63.0.815612128268.issue42091@roundup.psfhosted.org>


New submission from Pridhvi Myneni <bluerat33 at gmail.com>:

My system has python from MSYS2 integrated with my windows environment, so I can't test if Windows exhibits the same issue; however, this works perfectly in Ubuntu. The issue is %-d, %-I don't work as expected and instead cause the function call to return an empty string. 

Steps to reproduce:
import datetime
now = datetime.datetime.now()
now.strftime("%-I")
...

----------
messages: 379018
nosy: PMARINA
priority: normal
severity: normal
status: open
title: strftime returns empty string for -d, -I 3.8.3
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 19 17:22:22 2020
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 19 Oct 2020 21:22:22 +0000
Subject: [New-bugs-announce] [issue42092] test_host_resolution_bad_address
 does not always fail as expected
Message-ID: <1603142542.04.0.682089318313.issue42092@roundup.psfhosted.org>


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

This is very likely caused by something janky my ISP (AT&T) is doing with IPv6, but the above named test fails for me because IPv6 addresses like `::1q` do not fail to resolve as the test expects.

I'm not sure what can or should be done about it, but as this is an annoying local failure, and I couldn't find another mention of it by searching bpo, I wanted to at least get it on record.

The test function's comment says:

"
        # These are all malformed IP addresses and expected not to resolve to
        # any result.  But some ISPs, e.g. AWS, may successfully resolve these
        # IPs.
"

So apparently, put AT&T in that bucket of ISPs that resolve those IPv6 addresses.

----------
messages: 379020
nosy: barry
priority: normal
severity: normal
status: open
title: test_host_resolution_bad_address does not always fail as expected
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 19 23:18:36 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 20 Oct 2020 03:18:36 +0000
Subject: [New-bugs-announce] [issue42093] Add opcode cache for LOAD_ATTR
Message-ID: <1603163916.18.0.528007796853.issue42093@roundup.psfhosted.org>


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

>From the creators of "opcode cache for LOAD_GLOBAL" (https://bugs.python.org/issue26219) now it's time for "opcode cache for LOAD_ATTR: the revenge". This issue/PR builds on top of Yury's original patch in the same way https://bugs.python.org/issue26219 did for LOAD_GLOBAL. 

These are the benchmark results for the pyperformance test suite with PGO/LTO/CPU ISOLATION in a tuned system with pyperf:

+-------------------------+--------------------------------------+-------------------------------------+
| Benchmark               | 2020-10-20_01-18-master-de73d432bb29 | 2020-10-20_02-28-cache-68f931f6938a |
+=========================+======================================+=====================================+
| go                      | 407 ms                               | 349 ms: 1.17x faster (-14%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| raytrace                | 822 ms                               | 730 ms: 1.13x faster (-11%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| unpickle_pure_python    | 497 us                               | 447 us: 1.11x faster (-10%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| scimark_sor             | 311 ms                               | 280 ms: 1.11x faster (-10%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| hexiom                  | 15.4 ms                              | 14.0 ms: 1.10x faster (-9%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| logging_silent          | 302 ns                               | 276 ns: 1.10x faster (-9%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| chaos                   | 176 ms                               | 163 ms: 1.08x faster (-7%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| pyflate                 | 1.01 sec                             | 948 ms: 1.06x faster (-6%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| scimark_lu              | 246 ms                               | 232 ms: 1.06x faster (-6%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| pickle_pure_python      | 712 us                               | 674 us: 1.06x faster (-5%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| regex_effbot            | 4.49 ms                              | 4.26 ms: 1.05x faster (-5%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| scimark_monte_carlo     | 160 ms                               | 153 ms: 1.05x faster (-5%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| richards                | 120 ms                               | 115 ms: 1.05x faster (-4%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| 2to3                    | 458 ms                               | 442 ms: 1.04x faster (-4%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| regex_v8                | 33.7 ms                              | 32.5 ms: 1.04x faster (-3%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| scimark_sparse_mat_mult | 7.16 ms                              | 6.93 ms: 1.03x faster (-3%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| deltablue               | 12.1 ms                              | 11.7 ms: 1.03x faster (-3%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| regex_dna               | 268 ms                               | 261 ms: 1.03x faster (-3%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| meteor_contest          | 152 ms                               | 148 ms: 1.03x faster (-3%)          |
+-------------------------+--------------------------------------+-------------------------------------+
| genshi_xml              | 89.0 ms                              | 87.1 ms: 1.02x faster (-2%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| logging_simple          | 12.8 us                              | 12.5 us: 1.02x faster (-2%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| genshi_text             | 42.4 ms                              | 41.5 ms: 1.02x faster (-2%)         |
+-------------------------+--------------------------------------+-------------------------------------+
| nbody                   | 215 ms                               | 211 ms: 1.02x faster (-2%)          |
+-------------------------+--------------------------------------+-------------------------------------+

Not significant (35): chameleon; django_template; dulwich_log; fannkuch; float; json_dumps; json_loads; logging_format; mako; nqueens; pathlib; pickle; pickle_dict; pickle_list; pidigits; python_startup; python_startup_no_site; regex_compile; scimark_fft; spectral_norm; sqlalchemy_declarative; sqlalchemy_imperative; sqlite_synth; sympy_expand; sympy_sum; sympy_str; telco; tornado_http; unpack_sequence; unpickle; unpickle_list; xml_etree_parse; xml_etree_iterparse; xml_etree_generate; xml_etree_process; sympy_integrate

----------
assignee: pablogsal
components: Interpreter Core
messages: 379083
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Add opcode cache for LOAD_ATTR
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 20 03:13:53 2020
From: report at bugs.python.org (Erik Cederstrand)
Date: Tue, 20 Oct 2020 07:13:53 +0000
Subject: [New-bugs-announce] [issue42094] isoformat() / fromisoformat() for
 datetime.timedelta
Message-ID: <1603178033.64.0.797359415965.issue42094@roundup.psfhosted.org>


New submission from Erik Cederstrand <erik at cederstrand.dk>:

Python 3.7 gained support for parsing ISO 8601 formatted time, date and datetime strings via the fromisoformat() methods. Python has seen improved support for ISO 8601 in general; ISO calendar format codes were added in Python 3.6, and fromisocalendar() was added in Python 3.8.

ISO 8601 also has a standard for durations: https://en.wikipedia.org/wiki/ISO_8601#Durations

For consistency with the other objects in the datetime module, I suggest adding isoformat()/fromisoformat() methods for datetime.timedelta that implement ISO 8601 durations.

ISO 8601 durations support years and months that are not valid timedelta arguments because they are non-precise durations. I suggest throwing an exception if the conversion to or from timedelta cannot be done safely.

https://pypi.org/project/isodate/ implements a parse_duration() method that could be used for inspiration.

----------
components: Library (Lib)
messages: 379091
nosy: Erik Cederstrand
priority: normal
severity: normal
status: open
title: isoformat() / fromisoformat() for datetime.timedelta
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 20 03:24:21 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Oct 2020 07:24:21 +0000
Subject: [New-bugs-announce] [issue42095] plistlib: Add tests that compare
 with plutil(1)
Message-ID: <1603178661.31.0.803001342032.issue42095@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

plistlib is a library that reads and writes files that should be compatible with Apple tooling/libraries.

Add some tests that verify interop (when ran on macOS):
- Generate plist files with plistlib and parse with plutil
- Generate plist files with plutil and parse with plistlib

Do this both for xml and binary plist files.

----------
components: Library (Lib), macOS
keywords: easy
messages: 379094
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: plistlib: Add tests that compare with plutil(1)
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 20 04:51:47 2020
From: report at bugs.python.org (Alex Roussel)
Date: Tue, 20 Oct 2020 08:51:47 +0000
Subject: [New-bugs-announce] [issue42096] zipfile.is_zipfile incorrectly
 identifying a gzipped file as a zip archive
Message-ID: <1603183907.96.0.755065326181.issue42096@roundup.psfhosted.org>


New submission from Alex Roussel <alexandredrr14 at gmail.com>:

Hello, 

I've come across an issue that seems similar to the false positives problem outlined in this ticket (https://bugs.python.org/issue28494), however this issue relates to a single gzipped json file which is incorrectly identified as a .zip archive because (I suspect) is_zipfile is mistaking bytes in the file's data for the ending bytes that correspond to a .zip archive.

I'm afraid I'm not well versed on the way is_zipfile 'seeks' the bytes of a file to compare its magic number, so I apologise if my description isn't completely accurate. 

Here's my attempt at a summary of the problem:

My .json.gz file includes the correct magic number (1f8b) to identify it as a gzipped file, however when zipfile.is_zipfile is called on the filepath, it returns True.

I'm going to ask if I'm allowed to upload the file directly for you (it's work related), in the meantime I've included a head and tail of the file's hexdump below.

I am running Python 3.6.9 on Ubuntu 18.04.

----------

~/T?l?chargements ? python3                                                   
Python 3.6.9 (default, Oct  8 2020, 12:12:24) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> zipfile.is_zipfile('2020-10-18-1602979256-http_get_7549.json.gz')
True

----------

~/T?l?chargements ? xxd 2020-10-18-1602979256-http_get_7549.json.gz | head                   
00000000: 1f8b 0800 7090 8b5f 0003 ecbd 5993 e338  ....p.._....Y..8
00000010: 922e fa7e 7fc6 bcea 588a 8b28 8ad7 ec3c  ...~....X..(...<
00000020: 883b 292e e2be bc71 91b8 5394 b8f3 d8fd  .;)....q..S.....
00000030: ef17 9422 3223 22ab 2ab3 7ba6 67a6 e774  ..."2#".*.{.g..t
00000040: 5bab 4209 6175 7738 3e77 3880 fff3 6f71  [.B.auw8>w8...oq
00000050: d005 fff6 fffe 9bc1 ea96 451d 2629 6712  ..........E.&)g.
00000060: 853e 4202 830d 3145 7221 6af7 fe11 3ae9  .>B...1Er!j...:.
00000070: 1c0b f9e6 2db1 c0bf 25ea 38a9 1479 f650  ....-...%.8..y.P

----------

~/T?l?chargements ? xxd 2020-10-18-1602979256-http_get_7549.json.gz | tail
01d492b0: 98a2 3d5c 25e1 c5b8 d9c5 3287 c5d8 3d7c  ..=\%.....2...=|
01d492c0: 968f 3652 6fd4 4a0c 243b 166d 5640 97b5  ..6Ro.J.$;.mV at ..
01d492d0: 9308 8376 fe17 1fac 0c90 0fdb b3e3 4e4a  ...v..........NJ
01d492e0: 605c a870 5120 955b 6267 e318 406f e1e2  `\.pQ .[bg.. at o..
01d492f0: 2c50 12ec 5eb0 43cc 8d97 4daf 6017 3412  ,P..^.C...M.`.4.
01d49300: 3bdb 40ce 743f 7aa8 6ff9 f30d 796f f784  ;. at .t?z.o...yo..
01d49310: cec2 c45d b012 7e07 c70c dafd e16e fee2  ...]..~......n..
01d49320: c8a6 c01c 627f e004 f9c7 4770 e5e7 6bbf  ....b.....Gp..k.
01d49330: 44d5 97bb ffdf ffe7 ff03 2263 b46f 3d5c  D........."c.o=\
01d49340: cb04                                     ..

----------
components: Library (Lib)
messages: 379105
nosy: aroussel
priority: normal
severity: normal
status: open
title: zipfile.is_zipfile incorrectly identifying a gzipped file as a zip archive
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 20 10:36:31 2020
From: report at bugs.python.org (Andrew de Quincey)
Date: Tue, 20 Oct 2020 14:36:31 +0000
Subject: [New-bugs-announce] [issue42097] Python 3.7.9
 logging/threading/fork hang
Message-ID: <1603204591.66.0.845365232565.issue42097@roundup.psfhosted.org>


New submission from Andrew de Quincey <Adq at tvsquared.com>:

We've been having some mysterious hangs in our threaded code. Debugging with GDB shows it ends up deadlocking during logging inside logging._acquireLock()

I googled and found someone else with the same issue: https://stackoverflow.com/questions/62059975/python-multiprocessing-logging-hangs

I'm able to replicate this on python 3.7.9 on two entirely separate machines (one ubuntu, one arch linux), though I had to bump up the number of iterations to 1000.

----------
components: Library (Lib)
files: test.py
messages: 379132
nosy: Adq
priority: normal
severity: normal
status: open
title: Python 3.7.9 logging/threading/fork hang
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49531/test.py

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

From report at bugs.python.org  Tue Oct 20 15:17:14 2020
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 20 Oct 2020 19:17:14 +0000
Subject: [New-bugs-announce] [issue42098] Test suite should verify auditing
 events get triggered
Message-ID: <1603221434.24.0.924056156868.issue42098@roundup.psfhosted.org>


New submission from A.M. Kuchling <amk at amk.ca>:

During the 3.10 development process, a call to `sys.audit()` got accidentally removed from the glob module. No tests caught it.

This is clearly bad. sys.audit() is intended for security-related purposes and can result in operations being cancelled, so someone may be relying on a particular event being triggered to catch a risky situation. If we then accidentally remove the audit event, that's a security hole.

The test suite should be verifying that audit events get triggered when we expect.  Presumably we'll need some kind of context manager or assertion that will do something like: 

  with self.assertAuditEventTriggered('glob.glob', 'path'):    
    glob.glob('path')

----------
components: Tests
messages: 379154
nosy: akuchling
priority: normal
severity: normal
status: open
title: Test suite should verify auditing events get triggered
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 20 15:18:59 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 20 Oct 2020 19:18:59 +0000
Subject: [New-bugs-announce] [issue42099] Fix reference to ob_type in
 unionobject.c and ceval
Message-ID: <1603221539.38.0.388949807312.issue42099@roundup.psfhosted.org>


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

It is great that access to ob_type has been cleaned up to use an access macro.  There are two spots that still need fixing.

I think we should do something to help avoid this kind of thing slipping into the code in the future.  E.g. a special build flag that renames the ob_type member would work.  I'll make a separate bug for that.

----------
assignee: vstinner
components: Interpreter Core
messages: 379155
nosy: nascheme, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Fix reference to ob_type in unionobject.c and ceval
type: enhancement

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

From report at bugs.python.org  Tue Oct 20 16:35:05 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 20 Oct 2020 20:35:05 +0000
Subject: [New-bugs-announce] [issue42100] Add _PyType_GetModuleByDef
Message-ID: <1603226105.52.0.971925860816.issue42100@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

I would like to add an internal _PyType_GetModuleByDef function to unblock further work on isolating extension modules, as discussed here: https://mail.python.org/archives/list/capi-sig at python.org/thread/T3P2QNLNLBRFHWSKYSTPMVEIL2EEKFJU/

----------
messages: 379163
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Add _PyType_GetModuleByDef

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

From report at bugs.python.org  Tue Oct 20 17:18:09 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 20 Oct 2020 21:18:09 +0000
Subject: [New-bugs-announce] [issue42101] Allow inheritance of Venvs
Message-ID: <1603228689.04.0.730975944826.issue42101@roundup.psfhosted.org>


New submission from Matthias Bussonnier <bussonniermatthias at gmail.com>:

Followup from Python Idea: 

https://mail.python.org/archives/list/python-ideas at python.org/thread/KTIYUEYF6XBHOGOLV744RQXMTETVSTOF/

Goal would be to allow layering on virtualenv to speedup creation and use less disk space in the case of many large venv having the same base. 

This would be based on an private internal patch that would be upstreamed.

----------
messages: 379164
nosy: mbussonn
priority: normal
severity: normal
status: open
title: Allow inheritance of Venvs
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 20 17:48:49 2020
From: report at bugs.python.org (Shantanu)
Date: Tue, 20 Oct 2020 21:48:49 +0000
Subject: [New-bugs-announce] [issue42102] Make builtins.callable "generic"
Message-ID: <1603230529.81.0.174539582672.issue42102@roundup.psfhosted.org>


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

In the post PEP 585 world, it seems like a bit of a stumbling block for builtins.callable to not able to be parametrised (in a runtime context). Post PEP 604, I'd expect typing.Callable to be the most used typing import after typing.Any, so much of PEP 585's rationale should apply to this case too.

Concretely, one way to implement this would be to turn callable into a type whose __new__ returns a bool and which implements __class_getitem__. We could throw in an __instancecheck__ so that `isinstance(x, callable) == callable(x)`.


PS: Despite being code that crashes instantly, I was still able to find some instances of `isinstance(x, callable)` on popular Github projects: https://grep.app/search?q=isinstance%5C%28.%2A%2C%20callable%5C%29&regexp=true&case=true

----------
messages: 379169
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Make builtins.callable "generic"
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 20 20:25:11 2020
From: report at bugs.python.org (Robert Wessen)
Date: Wed, 21 Oct 2020 00:25:11 +0000
Subject: [New-bugs-announce] [issue42103] DoS (MemError via CPU and RAM
 exhaustion) when processing malformed Apple Property List files in binary
 format
Message-ID: <1603239911.48.0.657036824442.issue42103@roundup.psfhosted.org>


New submission from Robert Wessen <wessen at gmail.com>:

In versions of Python from 3.4-3.10, the Python core plistlib library supports Apple's binary plist format. When given malformed input, the implementation can be forced to create an argument to struct.unpack() which consumes all available CPU and memory until a MemError is thrown as it builds the 'format' argument to unpack().

This can be seen with the following malformed example binary plist input:

```
$ xxd binary_plist_dos.bplist
00000000: 6270 6c69 7374 3030 d101 0255 614c 6973  bplist00...UaLis
00000010: 74a5 0304 0506 0000 00df 4251 4351 44a3  t.........BQCQD.
00000020: 0809 0a10 0110 0210 0308 0b11 1719 1b1d  ................
00000030: 0000 0101 0000 0000 0000 000b 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0029            ...........)

```
The error is reached in the following lines of plistlib.py:
(https://github.com/python/cpython/blob/e9959c71185d0850c84e3aba0301fbc238f194a9/Lib/plistlib.py#L485)

```
    def _read_ints(self, n, size):
        data = self._fp.read(size * n)
        if size in _BINARY_FORMAT:
            return struct.unpack('>' + _BINARY_FORMAT[size] * n, data)
```
When the malicious example above is opened by plistlib, it results in 'n' being controlled by the input and it can be forced to be very large. Plistlib attempts to build a string which is as long as 'n', consuming excessive resources.

Apple's built in utilities for handling plist files detects this same file as malformed and will not process it.

----------
components: Interpreter Core
messages: 379175
nosy: wessen
priority: normal
severity: normal
status: open
title: DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format
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/issue42103>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:54:16 2020
From: report at bugs.python.org (karl)
Date: Wed, 21 Oct 2020 02:54:16 +0000
Subject: [New-bugs-announce] [issue42104] xml.etree should support
 contains() function
Message-ID: <1603248856.3.0.186912878202.issue42104@roundup.psfhosted.org>


New submission from karl <karl+pythonbugs at la-grange.net>:

In XPath 1.0 
The function contains() is available 

> Function: boolean contains(string, string)
> The contains function returns true if the first argument string contains the second argument string, and otherwise returns false.

In https://www.w3.org/TR/1999/REC-xpath-19991116/#function-contains


```
<body>
   <p class="doc">One attribute: doc</p>
   <p class="doc test">Two Attributes: doc test</p>
   <p class="test">One Attribute: test</p>
</body>
```

Currently, we can do this

```
>>> from lxml import etree
>>> root = etree.fromstring("""<body>
...    <p class="doc">One attribute</p>
...    <p class="doc test">Two Attributes: doc test</p>
...    <p class="doc2 test">Two Attributes: doc2 test</p>
... </body>
... """)
>>> elts = root.xpath("//p[@class='doc']")
>>> elts, etree.tostring(elts[0])
([<Element p at 0x102670900>], b'<p class="doc">One attribute</p>\n   ')
```


One way of extracting the list of 2 elements which contains the attribute doc with XPath is:


```
>>> root.xpath("//p[contains(@class, 'doc')]")
[<Element p at 0x1026708c0>, <Element p at 0x102670780>]
>>> [etree.tostring(elt) for elt in root.xpath("//p[contains(@class, 'doc')]")]
[b'<p class="doc">One attribute: doc</p>\n   ', b'<p class="doc test">Two Attributes: doc test</p>\n   ']
```


There is no easy way to extract all elements containing a "doc" value in a multi-values attribute in python 3.10 with xml.etree, which is quite common in html. 


```
>>> import xml.etree.ElementTree as ET
>>> root = ET.fromstring("""<body>
...    <p class="doc">One attribute: doc</p>
...    <p class="doc test">Two Attributes: doc test</p>
...    <p class="test">One Attribute: test</p>
... </body>"""
... )
>>> root.xpath("//p[contains(@class, 'doc')]")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 'xpath'
```

----------
components: Library (Lib)
messages: 379185
nosy: karlcow
priority: normal
severity: normal
status: open
title: xml.etree should support contains() function
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 21 05:44:15 2020
From: report at bugs.python.org (Ganesh Kumar)
Date: Wed, 21 Oct 2020 09:44:15 +0000
Subject: [New-bugs-announce] [issue42105] allow_abbrev not working as
 intended in "argparse.ArgumentParser" in Python 3.9.0
Message-ID: <1603273455.18.0.937271574309.issue42105@roundup.psfhosted.org>


New submission from Ganesh Kumar <ganesh-kumar at live.com>:

the "allow_abbrev" in "argparse.ArgumentParser" behavior does not work as intended in python 3.9.0

$ python3 --version
Python 3.5.3
$ python3 mcve.py -S
$ python3 mcve.py -SS
usage: mcve.py [-h] [-S]
mcve.py: error: unrecognized arguments: -SS

$ python3.9 --version
Python 3.9.0
$ python3.9 mcve.py -S
$ python3.9 mcve.py -SS # no erros raised here
$

Have attached a sample file to check this

----------
components: Library (Lib)
files: mcve.py
messages: 379202
nosy: Rin
priority: normal
severity: normal
status: open
title: allow_abbrev not working as intended in "argparse.ArgumentParser" in Python 3.9.0
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49533/mcve.py

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

From report at bugs.python.org  Wed Oct 21 05:59:57 2020
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 21 Oct 2020 09:59:57 +0000
Subject: [New-bugs-announce] [issue42106] docs.python.org prioritises search
 horribly
Message-ID: <1603274397.05.0.508797986319.issue42106@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

I expect it simply uses sphinx and I don't know if sphinx's search is easily customisable but the experience is really terrible when looking for the doc of a specific thing, *especially* when that thing is or is related to a builtin, which I'd expect to be extremely common. Though I expect part of the issue might also be that builtin or ABC methods are not documented *as such*, they're just written as code in tables.

For instance if you search "append": https://docs.python.org/3/search.html?q=append

On my end, neither list nor MutableSequence appear anywhere on this page, even scrolling down.

Searching for "list": https://docs.python.org/3/search.html?q=list

The documentation for the builtin "list" object also doesn't appear on the page. "Data Structures"[0] and "built-in types"[1] appear below the fold and the former is genuinely useful but also very easy to miss (I had not actually noticed it before going back in order to get the various links and try to extensively describe the issue). Neither actually links to the `list` builtin type though.

Above the fold we find various "list" methods and classes from the stdlib as well as the PDB `list` comment, none of which seems like the best match for the query.

And even Google doesn't help much there, most of the hits are for third-party documentation, and the one docs.python.org link is to the Data Structures page *of Python 2.7*.

[0] https://docs.python.org/3/tutorial/datastructures.html?highlight=list
[1] https://docs.python.org/3/library/stdtypes.html?highlight=list

----------
assignee: docs at python
components: Documentation
messages: 379203
nosy: docs at python, xmorel
priority: normal
severity: normal
status: open
title: docs.python.org prioritises search horribly
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 21 06:37:25 2020
From: report at bugs.python.org (Seth Junot)
Date: Wed, 21 Oct 2020 10:37:25 +0000
Subject: [New-bugs-announce] [issue42107] Monotonic time on macOS 10.12+
 should use mach_continuous_time()
Message-ID: <1603276645.14.0.842497391602.issue42107@roundup.psfhosted.org>


New submission from Seth Junot <xsetech at gmail.com>:

This blog post describes an issue with Apple's "CLOCK_UPTIME_RAW" where the clock is reset after a system that hibernates:

https://rachelbythebay.com/w/2020/10/20/ticktock/

According to Apple's documentation, CLOCK_UPTIME_RAW corresponds to mach_absolute_time():

https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time

CPython is using mach_absolute_time() for its time.monotonic() implementation:

https://github.com/python/cpython/blob/f660567/Python/pytime.c#L7

time.monotonic() ought to be backed by the more appropriate mach_continuous_time() ("CLOCK_MONOTONIC_RAW"). Note it was introduced in macOS 10.12+:

https://developer.apple.com/documentation/kernel/1646199-mach_continuous_time

----------
components: macOS
messages: 379204
nosy: ned.deily, ronaldoussoren, sjunot
priority: normal
severity: normal
status: open
title: Monotonic time on macOS 10.12+ should use mach_continuous_time()
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 21 10:28:09 2020
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Wed, 21 Oct 2020 14:28:09 +0000
Subject: [New-bugs-announce] [issue42108] HTTPSConnection hangs forever when
 the percentage completed of the upload drops from 100 to 0
Message-ID: <1603290489.3.0.079937646803.issue42108@roundup.psfhosted.org>


New submission from Micka?l Schoentgen <contact at tiger-222.fr>:

I will try to summarize my findings. I do not think having real data is revelant here, it seems to be a behavior issue.

I was originally using the `requests` module to `POST` some small data. The server will then do its stuff and it would take about 5 minutes to really complete. But for some reason, that call never ends.

I tried to isolate the "bad" code and tried more specific code: I reproduced the issue with `urllib3`, and then with `http.client.HTTPSConnection()`. I did not manage to go lower than that, but I may be able to try some C code with some help.

After having traced the script using `http.client.HTTPSConnection()`, the code is blocked at the `count = SSL_read(self->ssl, mem, len);` call [1].

This is it for the Python side.


Then, I translated the HTTP request to a cURL command (using the same machine, with the same headers and `POST` data). Surprisingly, atfer ~5 minutes, the call ended successfully.

Here is the verbose output of cURL:

  100   104    0     0  100   104      0    217 --:--:-- --:--:-- --:--:--   216
  100   104    0     0  100   104      0     70  0:00:01  0:00:01 --:--:--    70
  100   104    0     0  100   104      0     41  0:00:02  0:00:02 --:--:--    41
  100   104    0     0  100   104      0     29  0:00:03  0:00:03 --:--:--    29
  100   104    0     0  100   104      0     23  0:00:04  0:00:04 --:--:--    23
  100   104    0     0  100   104      0     18  0:00:05  0:00:05 --:--:--     0
  100   104    0     0  100   104      0     15  0:00:06  0:00:06 --:--:--     0
  100   104    0     0  100   104      0     13  0:00:08  0:00:07  0:00:01     0
  100   104    0     0  100   104      0     12  0:00:08  0:00:08 --:--:--     0
  100   104    0     0  100   104      0     10  0:00:10  0:00:09  0:00:01     0
  100   104    0     0  100   104      0      9  0:00:11  0:00:10  0:00:01     0
  100   104    0     0  100   104      0      9  0:00:11  0:00:11 --:--:--     0
  100   104    0     0  100   104      0      8  0:00:13  0:00:12  0:00:01     0
  100   104    0     0  100   104      0      7  0:00:14  0:00:13  0:00:01     0
  100   104    0     0  100   104      0      7  0:00:14  0:00:14 --:--:--     0
  100   104    0     0  100   104      0      6  0:00:17  0:00:15  0:00:02     0
  100   104    0     0  100   104      0      6  0:00:17  0:00:16  0:00:01     0
  100   104    0     0  100   104      0      5  0:00:20  0:00:17  0:00:03     0
  100   104    0     0  100   104      0      5  0:00:20  0:00:18  0:00:02     0
  100   104    0     0  100   104      0      5  0:00:20  0:00:19  0:00:01     0
  100   104    0     0  100   104      0      5  0:00:20  0:00:20 --:--:--     0
  100   104    0     0  100   104      0      4  0:00:26  0:00:21  0:00:05     0
  100   104    0     0  100   104      0      4  0:00:26  0:00:22  0:00:04     0
  100   104    0     0  100   104      0      4  0:00:26  0:00:23  0:00:03     0
  100   104    0     0  100   104      0      4  0:00:26  0:00:24  0:00:02     0
  100   104    0     0  100   104      0      4  0:00:26  0:00:25  0:00:01     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:26  0:00:08     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:27  0:00:07     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:28  0:00:06     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:29  0:00:05     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:30  0:00:04     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:31  0:00:03     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:32  0:00:02     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:33  0:00:01     0
  100   104    0     0  100   104      0      3  0:00:34  0:00:34 --:--:--     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:35  0:00:17     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:36  0:00:16     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:37  0:00:15     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:38  0:00:14     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:39  0:00:13     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:40  0:00:12     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:41  0:00:11     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:42  0:00:10     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:43  0:00:09     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:44  0:00:08     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:45  0:00:07     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:46  0:00:06     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:47  0:00:05     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:48  0:00:04     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:49  0:00:03     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:50  0:00:02     0
  100   104    0     0  100   104      0      2  0:00:52  0:00:51  0:00:01     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:52  0:00:52     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:53  0:00:51     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:54  0:00:50     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:55  0:00:49     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:56  0:00:48     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:57  0:00:47     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:58  0:00:46     0
  100   104    0     0  100   104      0      1  0:01:44  0:00:59  0:00:45     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:00  0:00:44     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:01  0:00:43     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:02  0:00:42     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:03  0:00:41     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:04  0:00:40     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:05  0:00:39     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:06  0:00:38     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:07  0:00:37     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:08  0:00:36     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:09  0:00:35     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:10  0:00:34     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:11  0:00:33     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:12  0:00:32     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:13  0:00:31     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:14  0:00:30     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:15  0:00:29     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:16  0:00:28     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:17  0:00:27     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:18  0:00:26     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:19  0:00:25     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:20  0:00:24     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:21  0:00:23     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:22  0:00:22     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:23  0:00:21     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:24  0:00:20     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:25  0:00:19     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:26  0:00:18     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:27  0:00:17     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:28  0:00:16     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:29  0:00:15     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:30  0:00:14     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:31  0:00:13     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:32  0:00:12     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:33  0:00:11     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:34  0:00:10     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:35  0:00:09     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:36  0:00:08     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:37  0:00:07     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:38  0:00:06     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:39  0:00:05     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:40  0:00:04     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:41  0:00:03     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:42  0:00:02     0
  100   104    0     0  100   104      0      1  0:01:44  0:01:43  0:00:01     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:44 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:45 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:46 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:47 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:48 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:49 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:50 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:51 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:52 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:53 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:54 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:55 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:56 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:57 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:58 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:01:59 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:00 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:01 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:02 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:03 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:04 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:05 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:06 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:07 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:08 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:09 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:10 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:11 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:12 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:13 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:14 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:15 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:16 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:17 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:18 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:19 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:20 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:21 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:22 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:23 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:24 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:25 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:26 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:27 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:28 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:29 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:31 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:32 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:33 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:34 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:35 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:36 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:37 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:38 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:39 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:40 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:41 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:42 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:43 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:44 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:45 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:46 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:47 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:48 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:49 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:50 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:51 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:52 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:53 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:54 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:55 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:56 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:57 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:58 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:02:59 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:00 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:01 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:02 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:03 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:04 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:05 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:06 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:07 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:08 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:09 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:10 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:11 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:12 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:13 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:14 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:15 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:16 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:17 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:18 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:19 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:20 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:21 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:22 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:23 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:24 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:25 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:26 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:27 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:28 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:29 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:30 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:31 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:32 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:33 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:34 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:35 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:36 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:37 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:38 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:39 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:40 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:41 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:42 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:43 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:44 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:45 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:46 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:47 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:48 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:49 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:50 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:51 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:52 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:53 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:54 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:55 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:56 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:57 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:58 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:03:59 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:00 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:01 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:02 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:03 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:04 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:05 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:06 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:07 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:08 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:09 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:10 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:11 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:12 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:13 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:14 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:15 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:16 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:17 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:18 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:19 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:20 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:21 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:22 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:23 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:24 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:25 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:26 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:27 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:28 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:29 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:30 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:31 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:32 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:33 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:34 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:35 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:36 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:37 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:38 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:39 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:40 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:41 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:42 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:43 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:44 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:45 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:46 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:47 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:48 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:49 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:50 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:51 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:52 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:53 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:54 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:55 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:56 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:57 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:58 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:04:59 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:00 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:01 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:02 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:03 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:04 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:05 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:06 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:07 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:08 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:09 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:10 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:11 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:12 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:13 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:14 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:15 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:16 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:17 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:18 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:19 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:20 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:21 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:22 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:23 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:24 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:25 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:26 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:27 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:28 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:29 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:30 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:31 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:32 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:33 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:34 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:35 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:36 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:37 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:38 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:39 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:40 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:41 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:42 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:43 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:44 --:--:--     0
  100   104    0     0    0   104      0      0 --:--:--  0:05:45 --:--:--     0

That output is explained here [2]. 

I am not an expert at all, but it does not make sens to me that the 5th column (percentage completed of the upload) drops from 100 to 0 at some point. And the request is still valid and continued.

Do you think I hit some corner-case bug here? I am desperate to move forward and can try anything to help debugging that issue.

Unfortunalty, the URL is private, and I have no power on the server (Tomcat). Even if there is something silly on the server, I would love to see Python making that HTTP call as cURL is handling it.

I may also say that doing the same request from a browser works too (using JavaScript). So it really seems Python-specific.

The issue is present since at least Python 3.7.7. I tried 3.7.8, 3.7.9, 3.8.6 and the master branch of today.

[1] https://github.com/python/cpython/blob/cb115e36e1aba04b90b0ecac6f043e60064ac65b/Modules/_ssl.c#L2586
[2] https://ec.haxx.se/cmdline/cmdline-progressmeter

----------
assignee: christian.heimes
components: SSL
messages: 379210
nosy: Tiger-222, christian.heimes
priority: normal
severity: normal
status: open
title: HTTPSConnection hangs forever when the percentage completed of the upload drops from 100 to 0
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 21 13:38:33 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 21 Oct 2020 17:38:33 +0000
Subject: [New-bugs-announce] [issue42109] Use hypothesis for testing the
 standard library, falling back to stubs
Message-ID: <1603301913.79.0.22425692211.issue42109@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

Following up on this year's language summit, I would like to propose that we start integrating property tests into the standard library. Zac Hatfield-Dodds (along with myself and Carl Friedrich Bolz-Tereick) have put together this repository of tests that we run against the standard library as is: https://github.com/Zac-HD/stdlib-property-tests

Here is the blog post covering the proposal from the language summit: https://pyfound.blogspot.com/2020/05/property-based-testing-for-python.html

The biggest challenges here are logistical:

1. Pulling in third party dependencies is difficult to do reliably on CI, but checking in hypothesis's entire dependency tree is probably not feasible.
2. We don't necessarily want to require developers running their tests locally to have to set up a hypothesis environment just to run the tests.
3. Hypothesis tests are not (by default) deterministic, which some are concerned may lead to flakiness by themselves.


To allay these concerns, I propose that we implement a compatibility interface for hypothesis that uses the third party module when it's installed, but otherwise falls back to stubs. The way I see the stubs working is that `@given` *without* `@example`s would simply skip the test. If you specify `@given` and one or more `@example`s, the test falls back to a simple parameterized test when hypothesis is not available.

At least at first, we won't attempt to add a mandatory PR job that runs with hypothesis installed. Instead, I'd like to run either an optional job on PR or have one or more buildbots that runs the hypothesis tests.

I would also like to suggest a policy of including at least one example in each property test, so that on PR at least some of the inputs are tested.

----------
assignee: p-ganssle
components: Tests
messages: 379226
nosy: Zac Hatfield-Dodds, p-ganssle, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Use hypothesis for testing the standard library, falling back to stubs
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 21 14:44:25 2020
From: report at bugs.python.org (Alan Jenkins)
Date: Wed, 21 Oct 2020 18:44:25 +0000
Subject: [New-bugs-announce] [issue42110] race condition in
 ThreadChildWatcher (default) and MultiLoopChildWatcher
Message-ID: <1603305865.86.0.468384454532.issue42110@roundup.psfhosted.org>


New submission from Alan Jenkins <alan.christopher.jenkins at gmail.com>:

## Test program ##

import asyncio
import time
import os
import signal
import sys

# This bug happens with the default, ThreadedChildWatcher
# It also happens with MultiLoopChildWatcher,
# but not the other three watcher types.
#asyncio.set_child_watcher(asyncio.MultiLoopChildWatcher())

# Patch os.kill to call sleep(1) first,
# opening up the window for a race condition
os_kill = os.kill
def kill(p, n):
    time.sleep(1)
    os_kill(p, n)

os.kill = kill

async def main():
    p = await asyncio.create_subprocess_exec(sys.executable, '-c', 'import sys; sys.exit(0)')
    p.send_signal(signal.SIGTERM)
    # cleanup
    await p.wait()

asyncio.run(main())


## Test output ##

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/alan-sysop/src/cpython/Lib/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/home/alan-sysop/src/cpython/Lib/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "<stdin>", line 3, in main
  File "/home/alan-sysop/src/cpython/Lib/asyncio/subprocess.py", line 138, in send_signal
    self._transport.send_signal(signal)
  File "/home/alan-sysop/src/cpython/Lib/asyncio/base_subprocess.py", line 146, in send_signal
    self._proc.send_signal(signal)
  File "/home/alan-sysop/src/cpython/Lib/subprocess.py", line 2081, in send_signal
    os.kill(self.pid, sig)
  File "<stdin>", line 3, in kill
ProcessLookupError: [Errno 3] No such process


## Tested versions ##

* v3.10.0a1-121-gc60394c7fc
* python39-3.9.0-1.fc32.x86_64
* python3-3.8.6-1.fc32.x86_64


## Race condition ##

main thread	vs	ThreadedChildWatcher._do_waitpid() thread

p=create_subprocess_exec(...)
			waitpid(...)  # wait for process exit
<Process p exits>
			<waitpid() returns.  Process p is reaped, and no longer exists>
p.send_signal(9)


## Result ##

A signal is sent to p.pid, after p.pid has been reaped by waitpid().  It might raise an error because p.pid no longer exists.

In the worst case the signal will be sent successfully - because an unrelated process has started with the same PID.


## How easy is it to reproduce? ##

It turns out the window for this race condition has been kept short, due to mitigations in the subprocess module.  IIUC, the mitigation protects against incorrect parallel use of a subprocess object by multiple threads.

        def send_signal(self, sig):
            # bpo-38630: Polling reduces the risk of sending a signal to the
            # wrong process if the process completed, the Popen.returncode
            # attribute is still None, and the pid has been reassigned
            # (recycled) to a new different process. This race condition can
            # happens in two cases [...]
            self.poll()
            if self.returncode is not None:
                # Skip signalling a process that we know has already died.
                return
            os.kill(self.pid, sig)




## Possible workarounds ##

* SafeChildWatcher and FastChildWatcher should not have this defect.  However we use ThreadedChildWatcher and MultiLoopChildWatcher to support running event loops in different threads.

* PidfdChildWatcher should not have this defect.  It is only available on Linux, kernel version 5.3 or above.

It would be possible to avoid the ThreadedChildWatcher race by using native code and pthread_cancel(), so that the corresponding waitpid() call is canceled before sending a signal.  Except the current implementation of pthread_cancel() is also unsound, because of race conditions.

* https://lwn.net/Articles/683118/ "This is why we can't have safe cancellation points"
* https://sourceware.org/bugzilla/show_bug.cgi?id=12683 "Race conditions in pthread cancellation"

----------
components: asyncio
messages: 379229
nosy: asvetlov, sourcejedi, yselivanov
priority: normal
severity: normal
status: open
title: race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 21 15:58:56 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 21 Oct 2020 19:58:56 +0000
Subject: [New-bugs-announce] [issue42111] Make the xxlimited module an
 example of best extension module practices
Message-ID: <1603310336.9.0.27411366123.issue42111@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP 
384 (Defining a Stable ABI), and is undocumented. As far as I can tell, 
it was added partly to test the stable ABI, and partly as an example of 
how to write a module (like "xx" from xxmodule.c).
In the last few years the module has not seen much maintenance, and I 
believe it's no longer a good example to follow: it works, but there are 
now better ways to do things.

I would like to take over maintenance of the module and make it into an 
example of how to write a low-level C extension with isolated module 
state, as described in PEP 630 (Isolating Extension Modules) -- an 
informational PEP that I plan to convert to a HOWTO doc when everything 
is ready.

The old module will be kept around to test the 3.5 stable ABI.

Past discussion: https://mail.python.org/archives/list/python-dev at python.org/thread/FO3YPG3YLG2XF5FKHICJHNINSPY4OHEL/#YITRQXGUOIEHK22QP5K4C5E45QA356U3

----------
components: C API
messages: 379241
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Make the xxlimited module an example of best extension module practices
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 21 16:16:37 2020
From: report at bugs.python.org (Matan Perelman)
Date: Wed, 21 Oct 2020 20:16:37 +0000
Subject: [New-bugs-announce] [issue42112] ZipFIle.write remove slash at the
 beginning of member's path
Message-ID: <1603311397.53.0.661224858745.issue42112@roundup.psfhosted.org>


Change by Matan Perelman <matan1008 at gmail.com>:


----------
components: Library (Lib)
nosy: matan1008
priority: normal
severity: normal
status: open
title: ZipFIle.write remove slash at the beginning of member's path
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 21 17:54:45 2020
From: report at bugs.python.org (Vladimir Matveev)
Date: Wed, 21 Oct 2020 21:54:45 +0000
Subject: [New-bugs-announce] [issue42113] Replace
 _asyncio.TaskWakeupMethWrapper with PyCFunction
Message-ID: <1603317285.99.0.989650690321.issue42113@roundup.psfhosted.org>


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

`TaskWakeupMethWrapper` looks like a more limited version of `PyCFunction` so it can be replaced with one.
Pros: remove a bunch of code, use better calling convention
Cons: now `wakeup` object will expose slightly more properties but I'm not sure whether this is bad

----------
components: asyncio
messages: 379258
nosy: asvetlov, v2m, yselivanov
priority: normal
severity: normal
status: open
title: Replace _asyncio.TaskWakeupMethWrapper with PyCFunction
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 21 18:02:15 2020
From: report at bugs.python.org (Joseph Fox-Rabinovitz)
Date: Wed, 21 Oct 2020 22:02:15 +0000
Subject: [New-bugs-announce] [issue42114] Documentation of
Message-ID: <1603317735.12.0.0166150677555.issue42114@roundup.psfhosted.org>


New submission from Joseph Fox-Rabinovitz <jfoxrabinovitz at gmail.com>:

ctypes.CDLL initializer defined in version 3.8 and beyond as

```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
             use_errno=False,
             use_last_error=False,
             winmode=None):
```

Documentation says `winmode=0`:

```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False, use_last_error=False, winmode=0)
```

Loading of normal DLL from custom directory works when `winmode=0`, but when `winmode=None` To reproduce, any combination of adding the fol += der containing the DLL to `os.evia ron['PATH']`, `os.add_dll_directory(...)`

Discoveryos.pathsep + ... triggered by https://stackoverflow.co, `sys.path.appen

Worked prior to 3.8 because there was no `winmode` parameter, and d(...)` does not change the behavior.m/q/`mode` was passed in directly, 59330863/298873`ctypes0. .DEFAULT_MODE == 0`.

I don't know whether it's better to update the code, the docs, or something else, but based on current info, would prefer updating the code.Some info summarized in https://stackoverflow.com/a/{8,9,}64472088/2988730.

Link to do pagecscorresponding : https://docs.python.org/3.10/library/ctypes.html#ctypes.CDLL
730.
Link to GitHub code: https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340

----------
components: ctypes
messages: 379261
nosy: madphysicist
priority: normal
severity: normal
status: open
title: Documentation of
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 21 23:21:38 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 22 Oct 2020 03:21:38 +0000
Subject: [New-bugs-announce] [issue42115] Caching infrastructure for the
 evaluation loop: specialised opcodes
Message-ID: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>


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

After https://bugs.python.org/issue42093 and https://bugs.python.org/issue26219 is being clear that we can leverage some cache for different information in the evaluation loop to speed up CPython. This observation is also based on the fact that although Python is dynamic, there is plenty of code that does not exercise said dynamism and therefore factoring out the "dynamic" parts of the execution by using a cache mechanism can yield excellent results. 

So far we have two big improvements in performance for caching LOAD_ATTR and LOAD_GLOBAL (in some cases up to 10-14%) but I think we can do much much more. Here are some observations of what I think we can do:

* Instead of adding more caches using the current mechanism, which adds some inlined code in every opcode in the evaluation loop, we can try to formalize some kind of caching mechanism that has some better API that will allow adding more opcodes in the future. Having the code inline in ceval.c is going to become difficult to maintain if we keep adding more stuff directly there.

* Instead of handling the specialization in the same opcode as the original one (LOAD_ATTR is doing the slow and the fast path) we could mutate the original code object and replacing the slow and generic opcodes for the more specialized ones and these will also be in charge of changing it back to the generic and slow ones if the assumptions that activated them appear.

Obviously, mutating code objects is scary, so we could have some "specialized" version of the bytecode in the cache and use that if is present. Ideas that we could do with this cached stuff:

- For binary operators, we can grab both operands, resolve the addition function and cache that together with the types and the version tags and if the types and the version tags are the same, use directly the addition function instead of resolving it.

- For loading methods, we could cache the bound method as proposed by Yury originally here: https://mail.python.org/pipermail/python-dev/2016-January/142945.html.

- We could also do the same for operations like "some_container[]" if the container is some builtin. We can substitute/specialize the opcode for someone that directly uses built-in operations instead of the generic BINARY_SUBSCR.

The plan will be:

- Making some infrastructure/framework for the caching that allows us to optimize/deoptimize individual opcodes.
- Refactor the existing specialization for LOAD_GLOBAL/LOAD_ATTR to use said infrastructure.
- Thinking of what operations could benefit from specialization and start adding them one by one.

----------
components: C API
messages: 379272
nosy: Mark.Shannon, methane, nascheme, pablogsal, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Caching infrastructure for the evaluation loop: specialised opcodes
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 22 06:48:43 2020
From: report at bugs.python.org (Gold Games)
Date: Thu, 22 Oct 2020 10:48:43 +0000
Subject: [New-bugs-announce] [issue42116] Inspect library ignore comments at
 the end of a function (inspect.getsource)
Message-ID: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>


New submission from Gold Games <noureddine.hamid at usmba.ac.ma>:

inspect.getsource ignore comments at the end of the function:

for example this function:

def matmul_single(A, x, out):
  from numpy import matmul
  out[:] = matmul(A, x)
  # Some comment here...

using the inspect library:
>>> inspect.getsource(matmul_single)                                                                                                                                     
>>> "def omp_matmul_single(A, x, out):\n  from numpy import matmul\n out[:] = matmul(A, x)\n"

the result does not contain the comments at the end of the function.

----------
components: Library (Lib)
messages: 379289
nosy: noureddine.hamid
priority: normal
severity: normal
status: open
title: Inspect library ignore comments at the end of a function (inspect.getsource)
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 22 09:47:16 2020
From: report at bugs.python.org (Blaze Spinnaker)
Date: Thu, 22 Oct 2020 13:47:16 +0000
Subject: [New-bugs-announce] [issue42117] asyncio calls from sync/async,
 better docs or api support
Message-ID: <1603374436.81.0.314726165729.issue42117@roundup.psfhosted.org>


New submission from Blaze Spinnaker <blazespinnaker at gmail.com>:

In jupyter / ipython, other repls, as well as from libraries,  asyncio code can be called.  To simplify integration, there should be a way for libraries to transparently do the right thing, call await or start a new global running event loop.  

This can be done without breaking the colored functions design constraint (only async can call async) and would not lead to dynamic coroutine architectures like gevent / lua.

The change would significantly reduce confusion that is pervasive in the python ecosystem and has lead to many people using a defacto approach of monkey patching (a monkey patch which only works on the surface).

Alternative, if this approach simply can not be accepted, better and more emphasized headline asyncio documentation would be appropriate to explain why the constraint is in place and the best patterns to use to work around the problem.   

It took me a lot of googling before I understood the reasoning of what is a very significant design choice.

There are many instances of this issue causing problems, but let me highlight this link:

https://github.com/ipython/ipykernel/issues/548#issuecomment-713637954

----------
components: asyncio
messages: 379292
nosy: asvetlov, blazespinnaker, yselivanov
priority: normal
severity: normal
status: open
title: asyncio calls from sync/async, better docs or api support
type: enhancement

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

From report at bugs.python.org  Thu Oct 22 11:38:20 2020
From: report at bugs.python.org (Jason Schwefel)
Date: Thu, 22 Oct 2020 15:38:20 +0000
Subject: [New-bugs-announce] [issue42118] TypeError gives wrong reserved name
Message-ID: <1603381100.92.0.596798918231.issue42118@roundup.psfhosted.org>


New submission from Jason Schwefel <jason.schwefel78 at gmail.com>:

The following code gives a "TypeError: 'str' object is not callable" exception:

int = ''
s = '3500:day'
a = s.split(':')
i = int(a[0])

Proper exception message should be "TypeError: 'int' object is not callable" 

Only able to test on 3.8 and 3.9

----------
components: Interpreter Core
messages: 379300
nosy: jason.schwefel78
priority: normal
severity: normal
status: open
title: TypeError gives wrong reserved name
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct 22 12:37:47 2020
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7oise_CONIL?=)
Date: Thu, 22 Oct 2020 16:37:47 +0000
Subject: [New-bugs-announce] [issue42119] Error when debugging
 logging.FileHandler subclass __init__ method
Message-ID: <1603384667.68.0.88562918356.issue42119@roundup.psfhosted.org>


New submission from Fran?oise CONIL <fcodvpt at gmail.com>:

In pdb, when I hit "a" to see __init__ parameters of a logging.FileHandler subclass, I get an error because __repr__ needs a logging level. The level has been removed from the parameters by configure_handler() when it instanciates the handler. The level is set after the handler instanciation.

I do not know if it can be changed or if I missed something.

Traceback (most recent call last):
  File "/usr/lib/python3.8/logging/config.py", line 563, in configure
    handler = self.configure_handler(handlers[name])
  File "/usr/lib/python3.8/logging/config.py", line 744, in configure_handler
    result = factory(**kwargs)
  File "/home/fconil/Progs/python/logging/multiprocesses-to-files-with-dict.py", line 53, in __init__
    pfilename = f"{filename}-{os.getpid()}.log"
  File "/home/fconil/Progs/python/logging/multiprocesses-to-files-with-dict.py", line 53, in __init__
    pfilename = f"{filename}-{os.getpid()}.log"
  File "/usr/lib/python3.8/bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/lib/python3.8/bdb.py", line 112, in dispatch_line
    self.user_line(frame)
  File "/usr/lib/python3.8/pdb.py", line 262, in user_line
    self.interaction(frame, None)
  File "/usr/lib/python3.8/pdb.py", line 357, in interaction
    self._cmdloop()
  File "/usr/lib/python3.8/pdb.py", line 322, in _cmdloop
    self.cmdloop()
  File "/usr/lib/python3.8/cmd.py", line 138, in cmdloop
    stop = self.onecmd(line)
  File "/usr/lib/python3.8/pdb.py", line 423, in onecmd
    return cmd.Cmd.onecmd(self, line)
  File "/usr/lib/python3.8/cmd.py", line 217, in onecmd
    return func(arg)
  File "/usr/lib/python3.8/pdb.py", line 1146, in do_args
    self.message('%s = %r' % (name, dict[name]))
  File "/usr/lib/python3.8/logging/__init__.py", line 1186, in __repr__
    level = getLevelName(self.level)
AttributeError: 'MultiFileHandler' object has no attribute 'level'

----------
components: Library (Lib)
files: multiprocesses-to-files-with-dict.py
messages: 379313
nosy: fcodvpt
priority: normal
severity: normal
status: open
title: Error when debugging logging.FileHandler subclass __init__ method
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file49535/multiprocesses-to-files-with-dict.py

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

From report at bugs.python.org  Thu Oct 22 15:08:50 2020
From: report at bugs.python.org (Erjia Guan)
Date: Thu, 22 Oct 2020 19:08:50 +0000
Subject: [New-bugs-announce] [issue42120] Depreciated MACRO of copysign for
 MSVC
Message-ID: <1603393730.66.0.233789813553.issue42120@roundup.psfhosted.org>


New submission from Erjia Guan <erjia at fb.com>:

At
https://github.com/python/cpython/blob/c60394c7fc9cc09b16e9675a3eeb5844b6d8523f/PC/pyconfig.h#L196, the MACRO converts copysign to _copysign. This MACRO is defined 13 years ago and it's really dangerous to define a lower-letter MACRO at this low level.
Currently, MSVC is supporting copysign (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/copysign-copysignf-copysignl-copysign-copysignf-copysignl?view=vs-2019).
I am requesting to remove this MACRO, as my customized copysign API will also be converted to _copysign on MSVC platform.

----------
components: C API
messages: 379323
nosy: ejguan
priority: normal
severity: normal
status: open
title: Depreciated MACRO of copysign for MSVC
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 22 16:54:54 2020
From: report at bugs.python.org (Xuan Wu)
Date: Thu, 22 Oct 2020 20:54:54 +0000
Subject: [New-bugs-announce] [issue42121] unable to input certain Unicode
 characters in Text widget
Message-ID: <1603400094.16.0.618856195633.issue42121@roundup.psfhosted.org>


New submission from Xuan Wu <nobodxbodon.github at gmail.com>:

When creating a text editor with tkinter Text widget, I found that some Chinese punctuations cound't be input correctly.

When input "?", which is open parenthesis in Chinese, it behaves like a back space.
When input "?", close parenthesis in Chinese, it seems like a tab instead.
When input "?", semicolon in Chinese, it does nothing.

Then I tried input the same in IDLE 3.7.6 and the same happened. Also, the same happens in thonny, the python IDE. I suppose they all use Text widget.

Pitifully I don't think of a way to reproduce the issue without using Chinese input method.

Please let me know how to help with debugging. Thanks.

----------
components: Tkinter
messages: 379345
nosy: nobodxbodon
priority: normal
severity: normal
status: open
title: unable to input certain Unicode characters in Text widget
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 22 19:27:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Oct 2020 23:27:09 +0000
Subject: [New-bugs-announce] [issue42122] IDLE complains about how fonts are
 accessed
Message-ID: <1603409230.0.0.859933553088.issue42122@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

This occurs immediately on startup:

$ python310 -m idlelib.idle
2020-10-22 16:20:19.400 python.exe[80008:1598908] CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:19.400 python.exe[80008:1598908] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
2020-10-22 16:20:19.450 python.exe[80008:1598908] CoreText note: Client requested name ".SF NS Mono", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:28.100 python.exe[80008:1598908] CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:28.100 python.exe[80008:1598908] CoreText note: Client requested name ".SF NS Mono", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:28.101 python.exe[80008:1598908] CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:28.124 python.exe[80008:1598908] CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:28.124 python.exe[80008:1598908] CoreText note: Client requested name ".SF NS Mono", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 16:20:28.124 python.exe[80008:1598908] CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].

----------
assignee: terry.reedy
components: IDLE
messages: 379382
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE complains about how fonts are accessed
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 22 19:35:43 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 22 Oct 2020 23:35:43 +0000
Subject: [New-bugs-announce] [issue42123] Run the two times,
 only enable invalid_* rules on the second run
Message-ID: <1603409743.28.0.787265357056.issue42123@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

We can avoid having to go through all the invalid rules (which might be a significant performance boost, since these may call expensive rules like primary or others), if we run the parser two times.

On the first run, all the invalid rules are disabled and do not get expanded. If a parse failure occurs anywhere, then we run the parser a second time with all these rules enabled, in order to get the correct error message.

Some benchmarking by Pablo show a ~4% speedup in the stdlib benchmark and a ~10% in the xxl benchmark.

----------
assignee: lys.nikolaou
components: Interpreter Core
messages: 379384
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Run the two times, only enable invalid_* rules on the second run
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 22 22:34:27 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Oct 2020 02:34:27 +0000
Subject: [New-bugs-announce] [issue42124] FAIL test_asyncio
 test_sendfile_close_peer_in_the_middle_of_receiving
Message-ID: <1603420467.19.0.337945390908.issue42124@roundup.psfhosted.org>


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

======================================================================
FAIL: test_sendfile_close_peer_in_the_middle_of_receiving (test.test_asyncio.test_sendfile.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\1\s\lib\test\test_asyncio\test_sendfile.py", line 458, in test_sendfile_close_peer_in_the_middle_of_receiving
    self.run_loop(
AssertionError: ConnectionError not raised

----------
components: Tests, asyncio
messages: 379397
nosy: asvetlov, terry.reedy, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: FAIL test_asyncio test_sendfile_close_peer_in_the_middle_of_receiving
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 01:26:53 2020
From: report at bugs.python.org (Eugene Toder)
Date: Fri, 23 Oct 2020 05:26:53 +0000
Subject: [New-bugs-announce] [issue42125] linecache cannot get source for
 the __main__ module with a custom loader
Message-ID: <1603430813.16.0.973913314648.issue42125@roundup.psfhosted.org>


New submission from Eugene Toder <eltoder at gmail.com>:

If a module has a loader, linecache calls its get_source() passing __name__ as the argument. This works most of the time, except that the __main__ module has it set to "__main__", which is commonly not the real name of the module. Luckily, we now have __spec__ which has the real name, so we can just use it.

Attached zip file reproduces the problem:
$ python t.zip
Traceback (most recent call last):
  ...
  File "t.zip/t.py", line 11, in <module>
  File "t.zip/t.py", line 8, in f
  File "t.zip/t.py", line 8, in f
  File "t.zip/t.py", line 8, in f
  [Previous line repeated 2 more times]
  File "t.zip/t.py", line 7, in f
ValueError

Note that entries from t.py don't have source code lines.

----------
components: Library (Lib)
files: t.zip
messages: 379408
nosy: eltoder
priority: normal
severity: normal
status: open
title: linecache cannot get source for the __main__ module with a custom loader
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49536/t.zip

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

From report at bugs.python.org  Fri Oct 23 04:46:51 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 23 Oct 2020 08:46:51 +0000
Subject: [New-bugs-announce] [issue42126] Optimize BUILD_CONST_KEY_MAP for
 distinct keys
Message-ID: <1603442811.66.0.361695425892.issue42126@roundup.psfhosted.org>


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

BUILD_CONST_KEY_MAP can be optimized based on #41835 optimization.

1. compiler checks keys tuple is distinct.
2. Add distinct flag to BUILD_CONST_KEY_MAP oparg

To be considered:

* Should we use new opcode, instead of flag in oparg?
* Is this technique safe? Wrong co_consts can make invalid dict instance.

----------
assignee: methane
components: Interpreter Core
messages: 379415
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize BUILD_CONST_KEY_MAP for distinct keys
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 10:51:35 2020
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Fri, 23 Oct 2020 14:51:35 +0000
Subject: [New-bugs-announce] [issue42127] functools.cached_property possibly
 disables key-sharing instance dictionaries
Message-ID: <1603464695.3.0.183922542861.issue42127@roundup.psfhosted.org>


New submission from Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:

Key-sharing dictionaries, defined by https://www.python.org/dev/peps/pep-0412/, require that any resizing of the shared dictionary keys will happen before a second instance of the class is created.

cached_property inserts its resolved result into the instance dict after it is called. This is likely to happen *after* a second instance has been created, and it is also likely to cause a resize of the dict, as demonstrated by this snippet:

    from functools import cached_property
    import sys

    def dict_size(o):
        return sys.getsizeof(o.__dict__)

    class X:
        def __init__(self):
            self.a = 1
            self.b = 2
            self.c = 3
            self.d = 4
            self.e = 5

        @cached_property
        def f(self):
            return id(self)

    x1 = X()
    x2 = X()

    print(dict_size(x1))
    print(dict_size(x2))

    x1.f

    print(dict_size(x1))
    print(dict_size(x2))

    x3 = X()
    print(dict_size(x3))

Essentially it means that types using cached_property are less likely to enjoy the benefits of shared keys. It may also incur a certain performance hit, because a resize + unshare will happen every time.

A simple way I've thought of to let cached_property play more nicely with shared keys, is to first create a single object of the class, and set the cached_property attribute to some value (so the key is added to the shared dict). In the snippet above, if you add "x0 = X(); x0.f = None" before creating x1 and x2, you'll see that the cached_property resolving does not unshare the dicts.

But I wonder if there's a way to do so without requiring user code changes.

----------
components: Library (Lib)
messages: 379439
nosy: Yonatan Goldschmidt
priority: normal
severity: normal
status: open
title: functools.cached_property possibly disables key-sharing instance dictionaries
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 11:22:20 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 23 Oct 2020 15:22:20 +0000
Subject: [New-bugs-announce] [issue42128] Structural Pattern Matching (PEP
 634)
Message-ID: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>


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

PEP 634 has not yet been accepted, but we'd like to hit the ground running and get this into alphas as soon as it (hopefully) is.

Several people have volunteered to review the implementation, since it's so huge. Other reviews are very welcome, if anybody has a bit of time to pitch in. This touches tons of stuff: the parser, the compiler, the VM, the builtins, the stdlib, the tests... I'd like as many eyeballs as possible!

I'll have a draft PR up against master in a few minutes. Let's try to keep all of the review comments there.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 379442
nosy: BTaskaya, brandtbucher, gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
stage: patch review
status: open
title: Structural Pattern Matching (PEP 634)
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 12:03:26 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Oct 2020 16:03:26 +0000
Subject: [New-bugs-announce] [issue42129] Support resources in namespace
 packages
Message-ID: <1603469006.87.0.128715336786.issue42129@roundup.psfhosted.org>


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

In [importlib_resources#68](https://github.com/python/importlib_resources/issues/68), the project identified a deficiency with respect to pkg_resources for resources in namespace packages.

The project has since merged support for these packages, slated to go out with the importlib_resources 3.2 release.

This issue is to track the incorporation of those changes into importlib.resources.

----------
assignee: jaraco
messages: 379451
nosy: jaraco
priority: normal
severity: normal
status: open
title: Support resources in namespace packages
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 12:10:29 2020
From: report at bugs.python.org (Taras Voinarovskyi)
Date: Fri, 23 Oct 2020 16:10:29 +0000
Subject: [New-bugs-announce] [issue42130] AsyncIO's wait_for can hide
 cancellation in a rare race condition
Message-ID: <1603469429.01.0.760360212477.issue42130@roundup.psfhosted.org>


New submission from Taras Voinarovskyi <voyn1991 at gmail.com>:

Hi, during migration to Python 3.8.6 we encountered a behavior change from previous versions: wait_for ignored the request to cancellation and returned instead. After investigation, it seems to be related to the update in bpo-32751 and is only reproduced if the waited task is finished when cancellation of wait_for happens (code mistakes external CancelledError for a timeout).

The following example can reproduce the behavior on both 3.8.6 and 3.9.0 for me:

```

import asyncio


async def inner():
    return

async def with_for_coro():
    await asyncio.wait_for(inner(), timeout=100)
    await asyncio.sleep(1)
    print('End of with_for_coro. Should not be reached!')

async def main():
    task = asyncio.create_task(with_for_coro())
    await asyncio.sleep(0)
    assert not task.done()
    task.cancel()
    print('Called task.cancel()')
    await task  # -> You would expect a CancelledError to be raised.


asyncio.run(main())
```

Changing the wait time before cancellation slightly will return the correct behavior and CancelledError will be raised.

----------
components: asyncio
messages: 379454
nosy: asvetlov, tvoinarovskyi, yselivanov
priority: normal
severity: normal
status: open
title: AsyncIO's wait_for can hide cancellation in a rare race condition
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 23 18:05:33 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 22:05:33 +0000
Subject: [New-bugs-announce] [issue42131] [zipimport] Update zipimport to
 use specs
Message-ID: <1603490733.54.0.490063164948.issue42131@roundup.psfhosted.org>


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

zipimport only supports old PEP 302 APIs and not PEP 451 module specs (i.e. it uses load_module() instead of create_module()/exec_module(), find_mdoule() instead of find_spec()).

Uses of both load_module() and find_module() are documented as deprecated for the import system and are slated to eventually go away.

----------
components: Library (Lib)
messages: 379481
nosy: brett.cannon, twouters
priority: normal
severity: normal
status: open
title: [zipimport] Update zipimport to use specs
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 18:16:01 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 22:16:01 +0000
Subject: [New-bugs-announce] [issue42132] Use specs instead of just
 __loader__ in C code
Message-ID: <1603491361.46.0.996069640716.issue42132@roundup.psfhosted.org>


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

_warnings.c, pylifecycle.c, and pythonrun.c all either use or set `__loader__` but without also falling back on `__spec__`.

----------
components: Interpreter Core
messages: 379483
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Use specs instead of just __loader__ in C code
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 18:46:40 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 22:46:40 +0000
Subject: [New-bugs-announce] [issue42133] Update the stdlib to fall back to
 __spec__.parent if __loader__ isn't defined
Message-ID: <1603493200.29.0.0849833372282.issue42133@roundup.psfhosted.org>


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

By making sure the stdlib can handle the case where __loader__ isn't defined but __spec__.parent is, eventually the former could be dropped for the latter.

----------
components: Library (Lib)
messages: 379486
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update the stdlib to fall back to __spec__.parent if __loader__ isn't defined
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 19:10:10 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 23:10:10 +0000
Subject: [New-bugs-announce] [issue42134] Raise ImportWarning when falling
 back to find_module()
Message-ID: <1603494610.04.0.950789467246.issue42134@roundup.psfhosted.org>


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

find_spec() has superseded find_module() since Python 3.4.

----------
components: Interpreter Core
messages: 379492
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Raise ImportWarning when falling back to find_module()
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 19:11:35 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 23:11:35 +0000
Subject: [New-bugs-announce] [issue42135] [importlib] Deprecate
 find_module() implementations
Message-ID: <1603494695.54.0.8376376438.issue42135@roundup.psfhosted.org>


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

find_spec() supersedes find_module() at this point.

----------
components: Library (Lib)
messages: 379493
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: [importlib] Deprecate find_module() implementations
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 19:18:48 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 23:18:48 +0000
Subject: [New-bugs-announce] [issue42136] [importlib] deprecate
 module_repr() methods
Message-ID: <1603495128.4.0.940710955069.issue42136@roundup.psfhosted.org>


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

The import system handles what `module_repr()` was meant for.

----------
components: Library (Lib)
messages: 379495
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: [importlib] deprecate module_repr() methods
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 19:20:55 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2020 23:20:55 +0000
Subject: [New-bugs-announce] [issue42137] Raise an ImportWarning for calling
 module_repr() on loaders
Message-ID: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>


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

Once all traces of module_repr() are gone, raise an `ImportWarning` when using `module_repr()`.

Once this is implemented and has been out in the wild for a sufficient amount of time, it should be switching to a DeprecationWarning and then the fallback eventually removed.

----------
components: Interpreter Core
messages: 379496
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Raise an ImportWarning for calling module_repr() on loaders
type: behavior

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

From report at bugs.python.org  Fri Oct 23 20:15:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 24 Oct 2020 00:15:56 +0000
Subject: [New-bugs-announce] [issue42138] Forward port Doc/whatsnew/3.9.rst
 to master
Message-ID: <1603498556.27.0.77301023463.issue42138@roundup.psfhosted.org>


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

We discovered in issue41950 that the whatsnew/3.9.rst files differ quite a bit between 3.9 and master. IIUC this is (mostly) because Lukasz made a big pass updating it on occasion of the 3.9.0 release, and he did that in the 3.9 branch:
https://github.com/python/cpython/commit/9cf6752276e6fcfd0c23fdb064ad27f448aaaf75#diff-ec874d66bbcf13046b9928aa3716d14a93632f568b914eba32baf46ff4c9eb36R1180

Historically we've kept these docs in sync.

For someone with a bit of git knowledge this should be a simple thing (probably just cp that thing into master).

----------
messages: 379501
nosy: gvanrossum, lukasz.langa
priority: normal
severity: normal
status: open
title: Forward port Doc/whatsnew/3.9.rst to master
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 23 23:25:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2020 03:25:45 +0000
Subject: [New-bugs-announce] [issue42139] Synchronize What's New in 3.9
 master and 3.9
Message-ID: <1603509945.65.0.000359045856286.issue42139@roundup.psfhosted.org>


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

Continuation of #41808, #41950, 9cf6752276e6fcfd0c23fdb064ad27f448aaaf75 (Langa, no diff).

Attached is a current diff (about 1/2 hour ago).  It appears to be all or almost all Langa's release edits in 9cf6752276e6fcfd0c23fdb064ad27f448aaaf75.  The important point is that all the +s are for the 3.9 version.  So the files can be synchronized easily by copying the 3.9 copy to master (each with separate workspaces).  I will re-update first to make sure to catch the changes in #41950.

----------
files: whatnew39-master-to-39.diff
keywords: patch
messages: 379513
nosy: gvanrossum, lukasz.langa, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Synchronize What's New in 3.9 master and 3.9
versions: Python 3.10
Added file: https://bugs.python.org/file49538/whatnew39-master-to-39.diff

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

From report at bugs.python.org  Sat Oct 24 02:51:22 2020
From: report at bugs.python.org (Diogo Dutra)
Date: Sat, 24 Oct 2020 06:51:22 +0000
Subject: [New-bugs-announce] [issue42140] asyncio.wait function creates
 futures set two times
Message-ID: <1603522282.48.0.50359686965.issue42140@roundup.psfhosted.org>


New submission from Diogo Dutra <diogodutradamata at gmail.com>:

The python3.9 code creates the futures set two times.
We can create this set before, avoiding the second creation.

This python3.9 behaviour breaks the aiokafka library, because it gives an iterator to that function, so the second iteration become empty.

----------
components: asyncio
messages: 379522
nosy: asvetlov, dutradda, yselivanov
priority: normal
pull_requests: 21858
severity: normal
status: open
title: asyncio.wait function creates futures set two times
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 24 17:17:49 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 24 Oct 2020 21:17:49 +0000
Subject: [New-bugs-announce] [issue42141] Speedup various dict inits
Message-ID: <1603574269.77.0.908879318121.issue42141@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

The PR #22948 is an augmented version of #22346. It speeds up also the creation of:

1. dicts from other dicts that are not "perfect" (combined and without holes)
2. fromkeys
3. copies of dicts with many holes
4. dict from keywords, as in #22346

A sample bench:

python -m pyperf timeit --rigorous "dict(o)" -s """
from uuid import uuid4

def getUuid():
    return str(uuid4())

o = {getUuid():getUuid() for i in range(1000)}
delkey = getUuid()
o[delkey] = getUuid()
del o[delkey]
"""
.........................................

Before #22948:
Mean +- std dev: 35.9 us +- 0.6 us

After:
Mean +- std dev: 26.4 us +- 0.4 us

----------
messages: 379540
nosy: Marco Sulla
priority: normal
pull_requests: 21865
severity: normal
status: open
title: Speedup various dict inits

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

From report at bugs.python.org  Sat Oct 24 19:29:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2020 23:29:20 +0000
Subject: [New-bugs-announce] [issue42142] FAIL tkinter ttk LabeledScale
 test_resize
Message-ID: <1603582160.73.0.386671878138.issue42142@roundup.psfhosted.org>


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

This appears to have timed out as there was no other error indication.
Azure Pipelines, retested gave 2nd failure.  Passed on another PR.

test_resize (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... Timeout (0:20:00)!
Thread 0x00007f787182e080 (most recent call first):
  File "/home/vsts/work/1/s/Lib/tkinter/__init__.py", line 696 in wait_visibility
  File "/home/vsts/work/1/s/Lib/tkinter/test/test_ttk/test_extensions.py", line 190 in test_resize
...

----------
messages: 379543
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: FAIL tkinter ttk LabeledScale test_resize
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 24 19:49:05 2020
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Sat, 24 Oct 2020 23:49:05 +0000
Subject: [New-bugs-announce] [issue42143] Corruptions in func_dealloc() with
 partially-created function object
Message-ID: <1603583345.9.0.605339724776.issue42143@roundup.psfhosted.org>


New submission from Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:

While reading funcobject.c, I noticed that PyFunction_NewWithQualName() may exit early if it fails retrieving __name__ from the globals dict.
It will destroy the partially-created PyFunction object. However, this is done before ever initializing ->func_qualname. Since the object is allocated with PyObject_GC_New() (which does *not* provide zero-initialized memory), we are using Py_CLEAR() on uninitialized memory.

I wrote a simple snippet to produce this bug, expecting to see a crash due to the Py_DECREF() call on garbage memory:

    from types import FunctionType
    import random

    class BadEq:
        def __hash__(self):
            print("hash called")
            return hash("__name__")
        def __eq__(self, other):
            print("eq called")
            raise Exception()

    # run until we hit a 0x61616161.. pointer for PyFunctionObject->func_qualname, and crash
    while True:
        s = int(random.random() * 1000) * "a"
        try:
            FunctionType(BadEq.__hash__.__code__, {BadEq(): 1})
        except Exception:
            pass

However, I got *another* crash immediately: func_dealloc() calls _PyObject_GC_UNTRACK() which crashes if _PyObject_GC_TRACK() was not called beforehand. When running with "--with-pydebug", you get this nice assert:

    Objects/funcobject.c:595: _PyObject_GC_UNTRACK: Assertion "(((PyGC_Head *)(op)-1)->_gc_next != 0)" failed: object not tracked by the garbage collector

I replaced "_PyObject_GC_UNTRACK(op);" in func_dealloc() with:

    if (PyObject_GC_IsTracked(op)) {
        _PyObject_GC_UNTRACK(op);
    }

And ran my snippet again, this time it crashes after some loops with the error I was expecting to receive
(here I print _py_tmp, the temporary variable inside Py_CLEAR()):

    Program received signal SIGSEGV, Segmentation fault.
    func_clear (op=op at entry=0x7f9c8a25faf0) at Objects/funcobject.c:587
    587     Py_CLEAR(op->func_qualname);
    (gdb) p _py_tmp
    $1 = (PyObject *) 0x6161616161616161

This issue exists since https://github.com/python/cpython/pull/11112, which fixed tons of call sites to use PyDict_GetItemWithError(), I guess that this specific flow was not tested.

As a fix, I think we should run the part that can result in errors *before* creating the PyFunction, so we can no longer get an error while we have a partial object. This fixes both of the problems I've described. Thus we can move the dict lookup part to the top of
PyFunction_NewWithQualName().

I see no reason not to make such a change in the function's flow. If we'd rather keep the flow as-is, we can make sure to initialize ->func_qualname to NULL, and wrap _PyObject_GC_UNTRACK() with _PyObject_GC_IS_TRACKED() in func_dealloc(). I like this solution less because it adds this unnecessary "if" statement in func_dealloc().

I'll post a PR in GitHub soon.

----------
components: Interpreter Core
messages: 379546
nosy: Yonatan Goldschmidt
priority: normal
severity: normal
status: open
title: Corruptions in func_dealloc() with partially-created function object
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct 25 00:51:47 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 25 Oct 2020 04:51:47 +0000
Subject: [New-bugs-announce] [issue42144] A missing "goto" in the _ssl
 module!
Message-ID: <1603601507.64.0.594640776307.issue42144@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

In the _ssl_configure_hostname() function, there's a missing "goto error;" if
SSL_set_tlsext_host_name() fails.

----------
assignee: christian.heimes
components: Extension Modules, SSL
messages: 379562
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: A missing "goto" in the _ssl module!
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 25 01:51:18 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 25 Oct 2020 05:51:18 +0000
Subject: [New-bugs-announce] [issue42145] test_io is leaking references
Message-ID: <1603605078.18.0.00514890587111.issue42145@roundup.psfhosted.org>


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

? ./python -m test test_io -m test.test_io.CTextIOWrapperTest.test_read_one_by_one -R :
0:00:00 load avg: 1.59 Run tests sequentially
0:00:00 load avg: 1.59 [1/1] test_io
beginning 9 repetitions
123456789
.........
test_io leaked [3, 3, 3, 3] references, sum=12
test_io leaked [1, 1, 1, 1] memory blocks, sum=4
test_io failed

== Tests result: FAILURE ==

1 test failed:
    test_io

Total duration: 398 ms
Tests result: FAILURE

----------
components: Tests
messages: 379564
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_io is leaking references
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct 25 08:30:55 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 25 Oct 2020 12:30:55 +0000
Subject: [New-bugs-announce] [issue42146] subprocess.Popen() leaks cwd in
 case of uid/gid overflow
Message-ID: <1603629055.61.0.677699237141.issue42146@roundup.psfhosted.org>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The following test demonstrates the leak:

```
import subprocess

cwd = 'x' * 10**6
for __ in range(100):
    try:
        subprocess.call(['/xxx'], cwd=cwd, user=2**64)
    except OverflowError:
        pass

from resource import *
print(getrusage(RUSAGE_SELF).ru_maxrss)
```

The leak was introduced by bpo-36046. Previously, `cleanup:` label was not reachable after `cwd_obj2` was initialized at https://github.com/python/cpython/blob/492d513ccbebeec40a8ba85cbd894a027ca5b2b3/Modules/_posixsubprocess.c#L892

I'll submit a PR with a simple fix suitable for backporting to 3.9.

Also, I think it might make sense to unify the two almost-identical cleanup paths we have now. I'll follow up with another PR.

----------
assignee: izbyshev
components: Extension Modules
keywords: 3.9regression
messages: 379575
nosy: gregory.p.smith, izbyshev, patrick.mclean
priority: normal
severity: normal
status: open
title: subprocess.Popen() leaks cwd in case of uid/gid overflow
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sun Oct 25 10:25:05 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 25 Oct 2020 14:25:05 +0000
Subject: [New-bugs-announce] [issue42147] Micro optimization for longrange
 iteration if step is 1
Message-ID: <1603635905.37.0.86802982801.issue42147@roundup.psfhosted.org>


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

This is a similar case with https://bugs.python.org/issue41902
A quite possible usecase when the user use range with big number

./python -m pyperf compare_to longrange_master.json longrange_opt.json
Mean +- std dev: [longrange_master] 6.45 us +- 0.09 us -> [longrange_opt] 5.72 us +- 0.07 us: 1.13x faster (-11%)

----------
assignee: corona10
components: Interpreter Core
files: bench_longrange.py
messages: 379578
nosy: corona10, methane, vstinner
priority: normal
severity: normal
status: open
title: Micro optimization for longrange iteration if step is 1
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49539/bench_longrange.py

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

From report at bugs.python.org  Sun Oct 25 12:49:56 2020
From: report at bugs.python.org (Andrea Tuccia)
Date: Sun, 25 Oct 2020 16:49:56 +0000
Subject: [New-bugs-announce] [issue42148] floating point representation
 issues
Message-ID: <1603644596.05.0.306482715682.issue42148@roundup.psfhosted.org>


New submission from Andrea Tuccia <andrea at tuccia.it>:

I'm noticing some floating point representation precision issues that occurs on all versions and platforms:

>>> 277*0.1
27.700000000000003
>>> 1.2-1.0
0.19999999999999996
>>> import numpy as np
>>> np.double(277*0.1)
27.700000000000003
>>> np.double(1.2-1.0)
0.19999999999999996
>>> np.longdouble(277*0.1)
27.700000000000002842
>>> np.longdouble(1.2-1.0)
0.19999999999999995559

Verified with python 2.7 to 3.8. On x86 (i386 and amd64) and ARM (32 and 64 bits). It does not occur in C, LUA, Perl, ...

----------
components: Interpreter Core, Library (Lib)
messages: 379589
nosy: atuccia
priority: normal
severity: normal
status: open
title: floating point representation issues
type: behavior

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

From report at bugs.python.org  Sun Oct 25 15:40:07 2020
From: report at bugs.python.org (Kostiantyn Mashukov)
Date: Sun, 25 Oct 2020 19:40:07 +0000
Subject: [New-bugs-announce] [issue42149] Python 'make test' failed inside
 ssh+tmux
Message-ID: <1603654807.77.0.904276076107.issue42149@roundup.psfhosted.org>


New submission from Kostiantyn Mashukov <mail at highrox.com>:

Short version:
When building python from source code on linux (Debian10 amd64) inside ssh+tmux session 'make test' ends up with some tests failed.
  
Long version:
Build environment - freshly installed Debian10-amd64 os. Added build dependency packages: libreadline-dev libbz2-dev libffi-dev liblzma-dev libssl-dev libsqlite3-dev libgdbm-dev libncursesw5-dev tk-dev libgdbm-compat-dev

If you ssh to this machine, start tmux and initiate build like this:
./configure && make && make test
the whole testing phase will fail due to some failed tests.
----------------------------------------
7 tests failed:                                                                                                                                                                               
   test_generators test_multiprocessing_fork                                                                                                                                                 
   test_multiprocessing_forkserver test_multiprocessing_spawn                                                                                                                                   
   test_pdb test_regrtest test_threading                                                                                                                                                     
                                                                                                                                                                                              
14 tests skipped:                                                                                                                                                                             
   test_devpoll test_gdb test_ioctl test_kqueue test_msilib                                                                                                                           
   test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly                                                                                                                         
    test_winconsoleio test_winreg test_winsound test_zipfile64                                                                                                                                
                                                                                                                                                                                              
7 re-run tests:                                                                                                                                                                               
    test_generators test_multiprocessing_fork                                                                                                                                                 
    test_multiprocessing_forkserver test_multiprocessing_spawn                                                                                                                                
    test_pdb test_regrtest test_threading                                                                                                                                                     
                                                                                                                                                                                              
Total duration: 10 min 34 sec                                                                                                                                                                 
Tests result: FAILURE then FAILURE
-----------------------------------------
Running the same build process on the same machine ends up fine, if running: locally inside xterm, locally inside xterm+tmux, remotely inside ssh only (without tmux).

----------
components: Build
messages: 379603
nosy: kmash
priority: normal
severity: normal
status: open
title: Python 'make test' failed inside ssh+tmux
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 25 17:11:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 25 Oct 2020 21:11:23 +0000
Subject: [New-bugs-announce] [issue42150] Buffer overflow in
 bad_single_statement (Parser/pegen.c)
Message-ID: <1603660283.41.0.765507012241.issue42150@roundup.psfhosted.org>


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

Building Python with the address sanitizer and executing ./python -m test test_repl -v shows this:

===========================================================
==26216==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200003990f at pc 0x5625406527b2 bp 0x7ffe8d621910 sp 0x7ffe8d621900
READ of size 1 at 0x60200003990f thread T0
    #0 0x5625406527b1 in bad_single_statement Parser/pegen.c:993
    #1 0x5625406527b1 in _PyPegen_run_parser Parser/pegen.c:1136
    #2 0x5625406529b8 in _PyPegen_run_parser_from_file_pointer Parser/pegen.c:1179
    #3 0x5625403f1945 in PyRun_InteractiveOneObjectEx Python/pythonrun.c:208
    #4 0x5625403f3cd9 in PyRun_InteractiveLoopFlags Python/pythonrun.c:115
    #5 0x5625403f4e3f in PyRun_AnyFileExFlags Python/pythonrun.c:74
    #6 0x562540181792 in pymain_run_stdin Modules/main.c:512
    #7 0x562540181792 in pymain_run_python Modules/main.c:601
    #8 0x562540182904 in Py_RunMain Modules/main.c:677
    #9 0x562540182904 in pymain_main Modules/main.c:707
    #10 0x562540182904 in Py_BytesMain Modules/main.c:731
    #11 0x7f25297aa151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
    #12 0x56254017f0bd in _start (/home/pablogsal/github/python/master/python+0x1640bd)

0x60200003990f is located 1 bytes to the left of 2-byte region [0x602000039910,0x602000039912)
allocated by thread T0 here:
    #0 0x7f2529b70459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x562540553416 in tok_nextc Parser/tokenizer.c:872
    #2 0x562540554eb7 in tok_get Parser/tokenizer.c:1190
    #3 0x562540559590 in PyTokenizer_Get Parser/tokenizer.c:1839
    #4 0x56254064f6dd in _PyPegen_fill_token Parser/pegen.c:584
    #5 0x5625406934a7 in statement_newline_rule Parser/parser.c:1296
    #6 0x5625406934a7 in interactive_rule Parser/parser.c:769
    #7 0x5625406934a7 in _PyPegen_parse Parser/parser.c:24823
    #8 0x562540652382 in _PyPegen_run_parser Parser/pegen.c:1111
    #9 0x5625406529b8 in _PyPegen_run_parser_from_file_pointer Parser/pegen.c:1179
    #10 0x5625403f1945 in PyRun_InteractiveOneObjectEx Python/pythonrun.c:208
    #11 0x5625403f3cd9 in PyRun_InteractiveLoopFlags Python/pythonrun.c:115
    #12 0x5625403f4e3f in PyRun_AnyFileExFlags Python/pythonrun.c:74
    #13 0x562540181792 in pymain_run_stdin Modules/main.c:512
    #14 0x562540181792 in pymain_run_python Modules/main.c:601
    #15 0x562540182904 in Py_RunMain Modules/main.c:677
    #16 0x562540182904 in pymain_main Modules/main.c:707
    #17 0x562540182904 in Py_BytesMain Modules/main.c:731
    #18 0x7f25297aa151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)

SUMMARY: AddressSanitizer: heap-buffer-overflow Parser/pegen.c:993 in bad_single_statement
Shadow bytes around the buggy address:
  0x0c047ffff2d0: fa fa 00 04 fa fa 00 01 fa fa 00 04 fa fa 00 04
  0x0c047ffff2e0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x0c047ffff2f0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 07
  0x0c047ffff300: fa fa 00 04 fa fa 00 04 fa fa 06 fa fa fa 00 fa
  0x0c047ffff310: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
=>0x0c047ffff320: fa[fa]02 fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047ffff330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047ffff340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047ffff350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047ffff360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047ffff370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==26216==ABORTING

----------
components: Interpreter Core
messages: 379607
nosy: lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Buffer overflow in bad_single_statement (Parser/pegen.c)
versions: Python 3.10

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

From report at bugs.python.org  Sun Oct 25 23:51:30 2020
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 26 Oct 2020 03:51:30 +0000
Subject: [New-bugs-announce] [issue42151] Pure Python xml.etree.ElementTree
 is missing default attribute values
Message-ID: <1603684290.04.0.0149631860455.issue42151@roundup.psfhosted.org>


New submission from Felix C. Stegerman <flx at obfusk.net>:

I originally reported this as a bug in PyPy, but it turns out that CPython's C implementation (_elementtree) behaves differently than the pure Python version (b/c it sets specified_attributes = 1).

PyPy issue with example code: https://foss.heptapod.net/pypy/pypy/-/issues/3333

----------
components: Library (Lib)
messages: 379637
nosy: obfusk
priority: normal
severity: normal
status: open
title: Pure Python xml.etree.ElementTree is missing default attribute values
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/issue42151>
_______________________________________

From report at bugs.python.org  Mon Oct 26 03:16:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Oct 2020 07:16:24 +0000
Subject: [New-bugs-announce] [issue42152] Use PyDict_Contains() and
 PyDict_SetDefault() instead of PyDict_GetItemIdWithError
Message-ID: <1603696584.2.0.298207751497.issue42152@roundup.psfhosted.org>


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


----------
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use PyDict_Contains() and PyDict_SetDefault() instead of PyDict_GetItemIdWithError

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

From report at bugs.python.org  Mon Oct 26 03:59:35 2020
From: report at bugs.python.org (Chris Xiao)
Date: Mon, 26 Oct 2020 07:59:35 +0000
Subject: [New-bugs-announce] [issue42153] doc: library imaplib a url not
 available
Message-ID: <1603699175.52.0.848588068568.issue42153@roundup.psfhosted.org>


New submission from Chris Xiao <c.cx at foxmail.com>:

jump to https://docs.python.org/3/library/imaplib.html#imap4-objects,

in the "See also" text, the url(https://www.washington.edu/imap/) of the University of Washington?s IMAP Information Center is not available.

----------
assignee: docs at python
components: Documentation
messages: 379650
nosy: chrisxiao, docs at python
priority: normal
severity: normal
status: open
title: doc: library imaplib a url not available
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 26 05:17:38 2020
From: report at bugs.python.org (john ryan)
Date: Mon, 26 Oct 2020 09:17:38 +0000
Subject: [New-bugs-announce] [issue42154] Bad proxy returned immediately
 after BaseManager server restarted
Message-ID: <1603703858.08.0.528057325979.issue42154@roundup.psfhosted.org>


New submission from john ryan <jryan at tactiq.co.uk>:

I am building an application that is made up of several separate processes, where each process is a python program. They are all started by the supervisord utility and execute within a venv running Python 3.8.5 (default, Aug 13 2020, 15:42:06) [GCC 7.5.0] on linux, under Ubuntu 18.04.

I am using a multiprocessing BaseManager to implement a repository of queues. Each process asks for a queue by name then uses put/get on that queue.

The application needs to be resilient so it must be possible to restart the respository process and have the various client processes re-connect to the queues hosted by it.

The problem I am getting is that the first call to `get_queue()` after restarting the BaseManager server process does not return a queue.

The sequence below shows some testing by hand. (My test environment runs Ubuntu in a virtualbox hosted on Windows 8.1)

Here I started the server in a different terminal then started python as below (both pythons in the same venv).

This works as expected with the first call to get_queue returning a queue.
```
(hydra_env) john at u1804-VirtualBox:~/sw/code/hydra$ python
Python 3.8.5 (default, Aug 13 2020, 15:42:06) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing.managers import BaseManager
>>> class QueueManager(BaseManager): pass
... 
>>> QueueManager.register('get_queue')
>>> mgr = QueueManager(address=('localhost', 50000), authkey=b'abracadabra' )
>>> mgr.connect()
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<multiprocessing.queues.Queue object at 0x7f98403c1820>
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<multiprocessing.queues.Queue object at 0x7f98403c1820>
```

Stop and restart the server to see the problem. The first call to get_queue seems to succeed but in fact it has failed as shown by the print(str...). The second call to get_queue succeeds.
```
>>> mgr.connect()
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<AutoProxy[get_queue] object, typeid 'get_queue' at 0x7f280afdc160; '__str__()' failed>
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<multiprocessing.queues.Queue object at 0x7ff5f1b46820>
```

The server logs show it sent queues on all 4 calls
```
^C(hydra_env) john at u1804-VirtualBox:~/sw/code/hydra$ python ../../trials/test_mgr.py 
starting
serving <multiprocessing.queues.Queue object at 0x7f98403c1820>
serving <multiprocessing.queues.Queue object at 0x7f98403c1820>
^C(hydra_env) john at u1804-VirtualBox:~/sw/code/hydra$ python ../../trials/test_mgr.py 
starting
serving <multiprocessing.queues.Queue object at 0x7ff5f1b46820>
serving <multiprocessing.queues.Queue object at 0x7ff5f1b46820>
```

I get the same behaviour if I re-instantiate the local manager object

```
>>> mgr = QueueManager(address=('localhost', 50000), authkey=b'abracadabra' )
>>> mgr.connect()
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<AutoProxy[get_queue] object, typeid 'get_queue' at 0x7f280afdc2b0; '__str__()' failed>
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<multiprocessing.queues.Queue object at 0x7ff8dabd7820>
>>>
```

I even get the same behaviour if I just call `get_queue()` after restarting the server (ie without explicitly reconnecting).

I would have expected the first call to `get_queue()` to return a valid queue since neither it nor the call to `connect()` raised any kind of error.

It seems to me that there is some kind of state held that is the underlying cause of the issue. I did some investigating in  but I was not able to work out what was happening.

I found that it was possible to get into a state where a valid queue was never returned by `get_queue()` if an error had been raised by `get_nowait()` first.

Stop the server

```
>>> q.get_nowait()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in get_nowait
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/managers.py", line 835, in _callmethod
    kind, result = conn.recv()
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/connection.py", line 414, in _recv_bytes
    buf = self._recv(4)
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/connection.py", line 383, in _recv
    raise EOFError
EOFError
```

Restart the server but do not call `get_queue()`

```
>>> q.get_nowait()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in get_nowait
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/managers.py", line 834, in _callmethod
    conn.send((self._id, methodname, args, kwds))
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/connection.py", line 206, in send
    self._send_bytes(_ForkingPickler.dumps(obj))
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/connection.py", line 411, in _send_bytes
    self._send(header + buf)
  File "/home/john/.pyenv/versions/3.8.5/lib/python3.8/multiprocessing/connection.py", line 368, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<AutoProxy[get_queue] object, typeid 'get_queue' at 0x7f1e21f63070; '__str__()' failed>
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<AutoProxy[get_queue] object, typeid 'get_queue' at 0x7f1e21f63130; '__str__()' failed>
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<AutoProxy[get_queue] object, typeid 'get_queue' at 0x7f1e21f63220; '__str__()' failed>
>>> q = mgr.get_queue('name', 'src'); print(str(q))
<AutoProxy[get_queue] object, typeid 'get_queue' at 0x7f1e21f631f0; '__str__()' failed>
```

This continued while I was testing, but returned a queue some time later so was perhaps stuck on a timeout.


Python 3.9.0 - I did a limited amount of testing on Python 3.9.0 and the results appeared to be the same.


The code for the test server is here

```
from multiprocessing.managers import BaseManager
from multiprocessing import Queue

class QueueManager(BaseManager):

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.__queues = {} # dict of instances keyed on qname

    def get_queue(self, qname: str, src: str) -> Queue:
        if qname not in self.__queues:
            self.__queues[qname] = Queue()
        the_q = self.__queues[qname]
        print(f'serving {the_q}')
        return the_q


def main() -> None:
    """main for a process serving queues forever"""
    mgr = QueueManager(address=('localhost', 50000), authkey=b'abracadabra' )
    QueueManager.register('get_queue', callable=mgr.get_queue)
    server_object = mgr.get_server()
    print('starting')
    server_object.serve_forever()


if __name__ == '__main__':
    main()

```

----------
components: Library (Lib)
messages: 379657
nosy: jryan
priority: normal
severity: normal
status: open
title: Bad proxy returned immediately after BaseManager server restarted
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 26 07:41:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Oct 2020 11:41:51 +0000
Subject: [New-bugs-announce] [issue42155]
 email.utils.parsedate_to_datetime() should return None when date cannot be
 parsed
Message-ID: <1603712511.56.0.0108062453896.issue42155@roundup.psfhosted.org>


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

Documentation says that parsedate_to_datetime() performs the same function as parsedata(), but on success returns a datetime.

parsedata() returns None when date cannot be parsed, but parsedate_to_datetime() raises TypeError.

>>> email.utils.parsedate("0")
>>> email.utils.parsedate_to_datetime("0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/email/utils.py", line 198, in parsedate_to_datetime
    *dtuple, tz = _parsedate_tz(data)
TypeError: cannot unpack non-iterable NoneType object

The other use case is passing None as arguments. Although it is not documented, but I seen the following code in wild:

    parsedate(header.get('Date'))

parsedate() and parsedate_tz() accept None, but parsedate_to_datetime() does not.

----------
components: Library (Lib), email
messages: 379661
nosy: barry, maxking, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: email.utils.parsedate_to_datetime() should return None when date cannot be parsed
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 26 09:33:05 2020
From: report at bugs.python.org (=?utf-8?q?Stefan_V=C3=B6lkl?=)
Date: Mon, 26 Oct 2020 13:33:05 +0000
Subject: [New-bugs-announce] [issue42156] Currency not correct for all
 locales
Message-ID: <1603719185.4.0.390571957235.issue42156@roundup.psfhosted.org>


New submission from Stefan V?lkl <stefan.voelkl at fotozupple.de>:

I found that the currency formatting does not work correctly for all locales. For example:

{{{
import locale

amount = 24.99
locale.setlocale(locale.LC_ALL, 'it_IT.UTF-8')

price = locale.currency(amount)

print(price)
}}}

returns "? 24,99".
It should return "24,99 ?", just like noted at http://publications.europa.eu/code/it/it-370303.htm
under "Posizione del simbolo (?) negli importi in cifre".

----------
components: Library (Lib)
messages: 379662
nosy: GiftZwergrapper, lemburg
priority: normal
severity: normal
status: open
title: Currency not correct for all locales
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct 26 13:05:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Oct 2020 17:05:20 +0000
Subject: [New-bugs-announce] [issue42157] Cleanup the unicodedata module
Message-ID: <1603731920.79.0.612011686263.issue42157@roundup.psfhosted.org>


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

Mohamed Koubaa and me are trying to convert the unicodedata module to the multi-phase initialization API (PEP 489) and to convert the UCD static type to a heap type in bpo-1635741.

The unicodedata extension module has some special cases:

* It has a C API exposes in Python as the "unicodedata.ucnhash_CAPI" PyCapsule object.
* In C, the unicodedata_functions array is used to define module functions *AND* unicodedata.UCD methods. It is unused to do that and makes the conversion more tricky.
* Most C functions have a "self" parameter which is used to choose between the current version of the Unicode database and the version 3.2.0 ("unicodedata.ucd_3_2_0").

There is also a unicodedata.UCD type which cannot be instanciated in Python. It is only used to create the unicodedata.ucd_3_2_0 instance.

In the commit 47e1afd2a1793b5818a16c41307a4ce976331649, I moved the private _PyUnicode_Name_CAPI structure to internal C API.

In the commit ddc0dd001a4224274ba6f83568b45a1dd88c6fc6, Mohammed added a ucd_type parameter to the UCD_Check() macro. I asked him to do that.

In the commit e6b8c5263a7fcf5b95d0fd4c900e5949eeb6630d, I added a "global module state" and a "state" parameter to most functions. This change prepares the code base to pass a UCD type instance to functions, to be able to have more than once UCD type when it will be converted to a heap type, one type per module instance.

The technical problem is that unicodedata_functions is used for module functions and UCD methods. Duplicating unicodedata_functions requires to duplicate a lot of code and comments.

Sadly, it does not seem easily possible to retrieve the "module state" ("state" variable) in functions since unicodedata_functions is reused for module functioins and UCD methods. Using "defining_class" in Argument Clinic would require to duplicate all unicodedata_functions functions, one flavor for module functions, one flavor for UCD type. It would also require to duplicate all docstrings, which means to increase the maintenance burden and introduce a risk of having inconsistencies.

Maybe we could introduce a new UCD instance which would be mapped to the current Unicode Character Database version, and module functions which be bounded methods of this type. But it sounds overkill to me.

By the way, Unicode 3.2 was released in 2002: 18 years ago. I don't think that it's still relevant in 2020 to keep backward compatibility with Unicode 3.2. I propose to deprecate unicodedata.ucd_3_2_0 and deprecate the unicodedate.UCD type. In Python 3.12, we will be able to remove a lot of code, and simplify the code a lot.

For now, we can convert unicodedata to the multi-phase initilization API (PEP 489) and convert UCD static type to a heap type by avoiding references to the UCD type. Rather than checking if self is an instance of UCD_Type, we can check if it is not a module (PyModule_Check). This is exactly what Mohammed proposed in the first place, but I misunderstood the whole issue and gave him bad advices.

----------
components: Library (Lib)
messages: 379673
nosy: vstinner
priority: normal
severity: normal
status: open
title: Cleanup the unicodedata module
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 26 13:56:56 2020
From: report at bugs.python.org (Dylan Van Assche)
Date: Mon, 26 Oct 2020 17:56:56 +0000
Subject: [New-bugs-announce] [issue42158] guess_format() MIME type doesn't
 guess n-quads, n-triples, notation3 and TriG
Message-ID: <1603735016.36.0.247111341461.issue42158@roundup.psfhosted.org>


New submission from Dylan Van Assche <me at dylanvanassche.be>:

guess_format() from lib/mimetypes.py doesn't guess correctly the following MIME types:

- .nq: application/n-quads (specification: https://www.w3.org/TR/n-quads/)
- .nt: application/n-triples (specification: https://www.w3.org/TR/n-triples/)
- .n3: text/n3 (specification: https://www.w3.org/TeamSubmission/n3/)
- .trig: application/trig (specification: https://www.w3.org/TR/trig/)

In these cases the default MIME type is returned: application/octet-stream

----------
components: Library (Lib)
messages: 379676
nosy: DylanVanAssche
priority: normal
severity: normal
status: open
title: guess_format() MIME type doesn't guess n-quads, n-triples, notation3 and TriG
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/issue42158>
_______________________________________

From report at bugs.python.org  Mon Oct 26 17:05:24 2020
From: report at bugs.python.org (Lisa Roach)
Date: Mon, 26 Oct 2020 21:05:24 +0000
Subject: [New-bugs-announce] [issue42159] AsyncMock restores stopped patch
 if same object stopped multiple times
Message-ID: <1603746324.52.0.94475530038.issue42159@roundup.psfhosted.org>


New submission from Lisa Roach <lisaroach14 at gmail.com>:

Hard to explain in the title, easier to see via a test case:

     async def async_func():
         raise Exception

    def test_simultaneous_mocks(self):
        class Test(IsolatedAsyncioTestCase):
            async def test_test(self):
                patcher1 = patch(f"{__name__}.async_func")
                patcher2 = patch(f"{__name__}.async_func")
                patcher1.start()
                await async_func()
                patcher2.start()
                await async_func()
                patcher1.stop()
                with self.assertRaises(Exception):
                    await async_func()
                patcher2.stop()
                with self.assertRaises(Exception): # Fails, mock is restored!
                    await async_func()

        test = Test("test_test")
        output = test.run()
        self.assertTrue(output.wasSuccessful()) # Fail


Calling stop() on the second patch actually restores the mock and causes the test to fail.

----------
assignee: lisroach
messages: 379687
nosy: lisroach
priority: normal
severity: normal
status: open
title: AsyncMock restores stopped patch if same object stopped multiple times
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 26 17:07:04 2020
From: report at bugs.python.org (Eric Wolf)
Date: Mon, 26 Oct 2020 21:07:04 +0000
Subject: [New-bugs-announce] [issue42160] unnecessary overhead in tempfile
Message-ID: <1603746424.31.0.446714198691.issue42160@roundup.psfhosted.org>


Change by Eric Wolf <robo-eric at gmx.de>:


----------
components: Library (Lib)
nosy: Deric-W
priority: normal
severity: normal
status: open
title: unnecessary overhead in tempfile
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 26 17:59:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Oct 2020 21:59:37 +0000
Subject: [New-bugs-announce] [issue42161] Remove private _PyLong_Zero and
 _PyLong_One variables
Message-ID: <1603749577.35.0.864358738107.issue42161@roundup.psfhosted.org>


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

In bpo-38858, I made the small integer singletons per interpreter: commit 630c8df5cf126594f8c1c4579c1888ca80a29d59. _PyLong_Zero and _PyLong_One variables are still shared by all interpreters, whereas subinterpreters must not share Python objects: see bpo-40533.

I propose to add new _PyLong_GetZero() and _PyLong_GetOne() functions to replace _PyLong_Zero and _PyLong_One variables. These functions will retrieve the singletons from tstate->interp->small_ints.

----------
components: Interpreter Core
messages: 379691
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove private _PyLong_Zero and _PyLong_One variables
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 26 18:17:00 2020
From: report at bugs.python.org (MaT1g3R)
Date: Mon, 26 Oct 2020 22:17:00 +0000
Subject: [New-bugs-announce] [issue42162] The license page for Python 3.0 is
 messed up
Message-ID: <1603750620.18.0.975456176895.issue42162@roundup.psfhosted.org>


New submission from MaT1g3R <peijun.ma at protonmail.com>:

Page in question: https://docs.python.org/3.0/license.html

The page still shows up in web searches (this is how I found the error)

I tracked down the error to this commit, but I couldn't find a relevant branch to fix it: 4ca04b67f00edabe86072446f059adcb70eafcdd

----------
assignee: docs at python
components: Documentation
messages: 379692
nosy: MaT1g3R, docs at python
priority: normal
severity: normal
status: open
title: The license page for Python 3.0 is messed up
type: behavior

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

From report at bugs.python.org  Mon Oct 26 18:21:52 2020
From: report at bugs.python.org (Chandan Singh)
Date: Mon, 26 Oct 2020 22:21:52 +0000
Subject: [New-bugs-announce] [issue42163] _replace() no longer works on
 platform.uname_result objects
Message-ID: <1603750912.81.0.950571190169.issue42163@roundup.psfhosted.org>


New submission from Chandan Singh <chandan at chandansingh.net>:

Starting from Python 3.9, it seems like the `_replace()` method no longer  works on `platform.uname_result` objects, that are returned by
`platform.uname()`. A simple example can be seen below, which works on Python 3.8, but not on Python 3.9.

```
>>> import platform
>>> result = platform.uname()
>>> result._replace(machine="x86_64")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/collections/__init__.py", line 448, in _replace
    result = self._make(_map(kwds.pop, field_names, self))
  File "/usr/local/lib/python3.9/collections/__init__.py", line 441, in _make
    raise TypeError(f'Expected {num_fields} arguments, got {len(result)}')
TypeError: Expected 5 arguments, got 6
```

I'm not sure if this is an intended change or an uninteded side-effect. The `_replace` method does work on simple namedtuple objects, and `uname_result` claims to be:

> largely compatible with a simple namedtumple` object except that 'platform' is resolved late and cached to avoid calling "uname" except when needed`

This late resolution is what's new in Python 3.9 and also the source of the issue  as far as I can tell. I suppose the answer may depend on how braod our definition of  "largely compatible" is.

For some context, we use `_replace` in the tests of our BuildStream project, which is why we ran into this. The fix is reasonably simple on our end by changing how we mock some bits. But I wanted to check here if it's considered a bug or not. For reference, this is the patch we neded on our end: https://gitlab.com/BuildStream/buildstream/-/merge_requests/2092.

----------
components: Library (Lib)
messages: 379694
nosy: cs-shadow
priority: normal
severity: normal
status: open
title: _replace() no longer works on platform.uname_result objects
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 26 18:34:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 26 Oct 2020 22:34:47 +0000
Subject: [New-bugs-announce] [issue42164] Python fails to compile in the
 Fedora Stable LTO buildbots
Message-ID: <1603751687.99.0.243163164232.issue42164@roundup.psfhosted.org>


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

I have been trying to diagnose this failure:

https://buildbot.python.org/all/#/builders/271/builds/710/steps/3/logs/stdio

it happens on these buildbots:

x86_64 fedora stable
ppc64le fedora stable (so 32 now)

It seems that CPython cannot be compiled with --with-lto regardless of the version:

https://buildbot.python.org/all/#/builders/336/builds/2145
https://buildbot.python.org/all/#/builders/426/builds/641
https://buildbot.python.org/all/#/builders/294/builds/986

This seems to indicate that something has changed in these buildbots somehow. Maybe the gcc installation is broken?

In my investigation, it seems that Python/compile.o is miscompiled.For example

FEDORA BUILDBOT with LTO:

[buildbot at python-builder2-rawhide cpython]$ nm Python/compile.o  | grep _Py_Mangle
In function ?assemble_lnotab?,
    inlined from ?assemble_emit? at Python/compile.c:5696:25,
    inlined from ?assemble? at Python/compile.c:6038:18:
Python/compile.c:5650:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 5650 |         *lnotab++ = k;
      |                   ^
         U _Py_Mangle


MY ARCH LINUX SYSTEM:

? nm Python/compile.o  | grep _Py_Mangle
00000000 T _Py_Mangle

It seems that the _Py_Mangle is not included in the object file. Is this a gcc bug? I have not been able to diagnose exactly where does this problem. It seems that the gcc version is "10.2.1" but I can correctly build CPython with LTO in my arch Linux machine with gcc 10.2.0.

Given that these are stable buildbots, could you investigate what is going on or report this to the gcc folks ar RedHat/Fedora? 

----

More interesting data:

Compiling with -O0 does not have a problem, but doing it with -O3 does.

With -O0:

[buildbot at python-builder2-rawhide cpython]$ nm Python/compile.o  | grep _Py_Mangle
00000000 T _Py_Mangle

With -O3:

[buildbot at python-builder2-rawhide cpython]$ nm Python/compile.o  | grep _Py_Mangle
         U _Py_Mangle

----------
components: Build
messages: 379696
nosy: cstratak, hroncok, pablogsal, petr.viktorin, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Python fails to compile in the Fedora Stable LTO buildbots
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 27 03:03:18 2020
From: report at bugs.python.org (hyoxt121)
Date: Tue, 27 Oct 2020 07:03:18 +0000
Subject: [New-bugs-announce] [issue42165] Question about converting numpy
 float to bytes (bug??)
Message-ID: <1603782198.74.0.214609178007.issue42165@roundup.psfhosted.org>


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

Hi! In order to convert numpy float to bytes, we are using tobytes() method:

import pickle
import numpy as np
pickle.loads(np.float64(0.34103))

and the expected result is like below (because np.float64(0.34103) is not bytes objects, appropriate errors are expected)
---------------------------------------------------------------------------
UnpicklingError Traceback (most recent call last)
<ipython-input-19-5c07606a60f1> in <module>
----> 1 pickle.loads(np.float64(0.34103))

UnpicklingError: invalid load key, '\xc1'.


Here we have some questions that some numbers (it is rare) like 0.34104 prints the following result without errors.
pickle.loads(np.float64(0.34104))
=> True

This occurs only when the converted bytes start with b'\x88 (for example 0.04263, 0.08526, 0.11651 ...)
Can anyone answer whether this issue is Python bugs?

Any answer will be highly appreciated.

----------
components: Library (Lib)
messages: 379738
nosy: hyoxt121
priority: normal
severity: normal
status: open
title: Question about converting numpy float to bytes (bug??)
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 27 04:22:55 2020
From: report at bugs.python.org (kannan)
Date: Tue, 27 Oct 2020 08:22:55 +0000
Subject: [New-bugs-announce] [issue42166] corrupted size vs. prev_size
Message-ID: <1603786975.91.0.349324369107.issue42166@roundup.psfhosted.org>


New submission from kannan <kannaninfo93 at gmail.com>:

Getting the below error from long running python processes
----------------------------------------------------------

2020-10-18T21:52:59.383Z ======= Backtrace: =========
2020-10-18T21:52:59.383Z /lib64/libc.so.6(+0x7f3e4)[0x7f7bd3e053e4]
2020-10-18T21:52:59.383Z /lib64/libc.so.6(+0x814db)[0x7f7bd3e074db]
2020-10-18T21:52:59.383Z /lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x7f7bd1cfe80d]
2020-10-18T21:52:59.383Z /lib64/libssl.so.10(+0x41aa3)[0x7f7bd2134aa3]
2020-10-18T21:52:59.383Z /lib64/libssl.so.10(SSL_CTX_free+0x147)[0x7f7bd2136977]
2020-10-18T21:52:59.383Z /usr/local/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so(+0xe50b)[0x7f7bcf9d750b]
2020-10-18T21:52:59.383Z /lib64/libpython3.7m.so.1.0(+0x101bab)[0x7f7bd4db1bab]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xe2416)[0x7f7bd4d92416]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0x101ca1)[0x7f7bd4db1ca1]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xca6d9)[0x7f7bd4d7a6d9]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0x1f6255)[0x7f7bd4ea6255]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0x19fede)[0x7f7bd4e4fede]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyObject_GC_Malloc+0x133)[0x7f7bd4e50943]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyObject_GC_New+0xd)[0x7f7bd4e5099d]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xe3fdf)[0x7f7bd4d93fdf]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(PyObject_GetIter+0x16)[0x7f7bd4d62d86]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x133a)[0x7f7bd4e0c55a]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(+0xc562b)[0x7f7bd4d7562b]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0xa16)[0x7f7bd4e0bc36]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalCodeWithName+0x27e)[0x7f7bd4e1602e]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallKeywords+0xda)[0x7f7bd4d6d4aa]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x4f34)[0x7f7bd4e10154]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalCodeWithName+0x27e)[0x7f7bd4e1602e]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallKeywords+0xda)[0x7f7bd4d6d4aa]
2020-10-18T21:52:59.384Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x4f34)[0x7f7bd4e10154]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0xbcdfa)[0x7f7bd4d6cdfa]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x4f34)[0x7f7bd4e10154]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0xbcdfa)[0x7f7bd4d6cdfa]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x79c)[0x7f7bd4e0b9bc]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0xbcdfa)[0x7f7bd4d6cdfa]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallDict+0x66)[0x7f7bd4d6cfc6]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyObject_Call_Prepend+0x7b)[0x7f7bd4d6ef0b]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0x107b81)[0x7f7bd4db7b81]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0x1038a2)[0x7f7bd4db38a2]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyObject_FastCallKeywords+0x99)[0x7f7bd4d6dc89]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x52c5)[0x7f7bd4e104e5]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0xbcdfa)[0x7f7bd4d6cdfa]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x4f34)[0x7f7bd4e10154]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(+0xbcdfa)[0x7f7bd4d6cdfa]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallDict+0x66)[0x7f7bd4d6cfc6]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x1fd8)[0x7f7bd4e0d1f8]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalCodeWithName+0x27e)[0x7f7bd4e1602e]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallKeywords+0xda)[0x7f7bd4d6d4aa]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x4c4)[0x7f7bd4e0b6e4]
2020-10-18T21:52:59.385Z /lib64/libpython3.7m.so.1.0(_PyEval_EvalCodeWithName+0x27e)[0x7f7bd4e1602e]

----------
assignee: christian.heimes
components: SSL
messages: 379743
nosy: christian.heimes, kannanf9t
priority: normal
severity: normal
status: open
title: corrupted size vs. prev_size
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct 27 05:54:48 2020
From: report at bugs.python.org (Patrick Reader)
Date: Tue, 27 Oct 2020 09:54:48 +0000
Subject: [New-bugs-announce] [issue42167] Documentation for SETUP_WITH
 opcode is wrong
Message-ID: <1603792488.66.0.729213845644.issue42167@roundup.psfhosted.org>


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

bpo-33387 introduced two new opcodes, `RERAISE` and `WITH_EXCEPT_START` (previously called `WITH_EXCEPT_FINISH`), replacing the previous `WITH_CLEANUP_START`, `WITH_CLEANUP_FINISH`,
`BEGIN_FINALLY`, `END_FINALLY`, `CALL_FINALLY` and `POP_FINALLY`.

The [documentation](https://docs.python.org/3.9/library/dis.html#opcode-SETUP_WITH) for it references the since removed `WITH_CLEANUP_START`, which is definitely wrong. I don't know enough to be able to fix it though, sorry, so I've added the core team.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 379749
nosy: docs at python, pxeger
priority: normal
severity: normal
status: open
title: Documentation for SETUP_WITH opcode is wrong
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Oct 27 06:10:42 2020
From: report at bugs.python.org (hyoxt121)
Date: Tue, 27 Oct 2020 10:10:42 +0000
Subject: [New-bugs-announce] [issue42168] Question about deserializing some
 numbers (bug??)
Message-ID: <1603793442.12.0.906245378018.issue42168@roundup.psfhosted.org>


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

Hi! In order to deserialize bytes object, we use pickle.loads():

import pickle
import numpy as np
pickle.loads(np.float64(0.34103))

and the expected result is like below (because np.float64(0.34103) is not bytes objects, appropriate errors are expected)
---------------------------------------------------------------------------
UnpicklingError Traceback (most recent call last)
<ipython-input-19-5c07606a60f1> in <module>
----> 1 pickle.loads(np.float64(0.34103))

UnpicklingError: invalid load key, '\xc1'.


Here we have some questions that some numbers (it is rare) like 0.34104 prints the following result without errors.
pickle.loads(np.float64(0.34104))
=> True

This occurs only when the converted bytes start with b'\x88 (for example 0.04263, 0.08526, 0.11651 ...)
np.float64(0.34104).tobytes()
=> b'\x88.\xa8o\x99\xd3\xd5?'
Can anyone answer whether this issue is Python bugs?

Any answer will be highly appreciated.

----------
components: Library (Lib)
messages: 379750
nosy: hyoxt121
priority: normal
severity: normal
status: open
title: Question about deserializing some numbers (bug??)
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 27 06:59:52 2020
From: report at bugs.python.org (Peilonrayz)
Date: Tue, 27 Oct 2020 10:59:52 +0000
Subject: [New-bugs-announce] [issue42169] Apparently all documentation on
 @typing.overload is wrong
Message-ID: <1603796392.82.0.758366735277.issue42169@roundup.psfhosted.org>


New submission from Peilonrayz <peilonrayz at gmail.com>:

The documentation for `typing.overload` says in a non-stub file the last definition shouldn't be typed. However running that through `mypy --strict` fails. I opened an issue on mypy a couple of days ago, however was told to report this on CPython.

```
>>> import typing
>>> help(typing.overload)
Help on function overload in module typing:

overload(func)
    Decorator for overloaded functions/methods.
    
    In a stub file, place two or more stub definitions for the same
    function in a row, each decorated with @overload.  For example:
    
      @overload
      def utf8(value: None) -> None: ...
      @overload
      def utf8(value: bytes) -> bytes: ...
      @overload
      def utf8(value: str) -> bytes: ...
    
    In a non-stub file (i.e. a regular .py file), do the same but
    follow it with an implementation.  The implementation should *not*
    be decorated with @overload.  For example:
    
      @overload
      def utf8(value: None) -> None: ...
      @overload
      def utf8(value: bytes) -> bytes: ...
      @overload
      def utf8(value: str) -> bytes: ...
      def utf8(value):
          # implementation goes here
```

The typing docs and PEP 484 say similar things.  
typing docs - https://docs.python.org/3/library/typing.html#typing.overload  
PEP 484 - https://www.python.org/dev/peps/pep-0484/#function-method-overloading

Jelle Zijlstra told me to report this here. https://github.com/python/mypy/issues/9633#issuecomment-716201251

> You should annotate the implementation. The example in the typing docs should perhaps also add an annotation, but that's an issue for the CPython repo, not for mypy.

Either way mypy errors which can be seen in the following playgrounds.

docs - https://mypy-play.net/?mypy=latest&python=3.9&flags=strict&gist=cffb94a2de9d5d55142da5e7d960102f
```
main.py:9: error: Function is missing a type annotation
Found 1 error in 1 file (checked 1 source file)
```

proper way? - https://mypy-play.net/?mypy=latest&python=3.9&gist=bfadffe92571b4faad04ea151b2b1c54
```
main.py:3: error: An overloaded function outside a stub file must have an implementation
Found 1 error in 1 file (checked 1 source file)
```

Is all the documentation on `typing.overload` wrong - should the implementation be annotated?

----------
assignee: docs at python
components: Documentation
messages: 379754
nosy: docs at python, peilonrayz
priority: normal
severity: normal
status: open
title: Apparently all documentation on @typing.overload is wrong
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/issue42169>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:09:04 2020
From: report at bugs.python.org (Quentin Peter)
Date: Tue, 27 Oct 2020 14:09:04 +0000
Subject: [New-bugs-announce] [issue42170] splitdrive fails for UNC path with
 the "\\?\UNC\" prefix.
Message-ID: <1603807744.11.0.30805370189.issue42170@roundup.psfhosted.org>


Change by Quentin Peter <qpeter at bluewin.ch>:


----------
components: Library (Lib)
nosy: qpeter
priority: normal
severity: normal
status: open
title: splitdrive fails for UNC path with the "\\?\UNC\" prefix.
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct 27 10:50:49 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 27 Oct 2020 14:50:49 +0000
Subject: [New-bugs-announce] [issue42171] Add PEP 573 to the stable ABI
Message-ID: <1603810249.77.0.333997046365.issue42171@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

The following PEP 573 were not added to the Windows list of stable ABI symbols (PC/python3dll.c):
- PyModule_AddType
- PyType_FromModuleAndSpec
- PyType_GetModule
- PyType_GetModuleState

I'd like to add them.

Also, the PEP introduces the (METH_FASTCALL | METH_KEYWORDS | METH_METHOD) calling convention, but METH_FASTCALL is not part of the stable ABI (and it other uses are not suitable for stable ABI).
I propose adding a new value, METH_METHOD_ARGS_KWD (name up for bikeshedding), which would be equal to (METH_FASTCALL | METH_KEYWORDS | METH_METHOD) but part of the limited API.

Does that sound like a good idea?


On the sprint, Steve mentioned that it would be possible to backport this to Python 3.9.1, even though it would mean a weird minor-version requirement.
I no longer think that's a good idea: fixing the stable ABI will be a longer-term project, and I don't want to fight issues in a 3.9 backport.

FWIW, for the longer-term project, I started a brainstorming repo at https://github.com/encukou/abi3 (Yes, it has some overlap with Victor's more general notes at https://pythoncapi.readthedocs.io/ )
But I'd like to get the additions above in to unblock #42111 before I start on improving the stable ABI in general.

----------
components: C API
messages: 379762
nosy: ncoghlan, petr.viktorin, scoder, vstinner
priority: normal
severity: normal
status: open
title: Add PEP 573 to the stable ABI
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 27 11:12:18 2020
From: report at bugs.python.org (Akashkumar D Khunt)
Date: Tue, 27 Oct 2020 15:12:18 +0000
Subject: [New-bugs-announce] [issue42172] Typo in test library for
 test_socket.py
Message-ID: <1603811538.08.0.134266779609.issue42172@roundup.psfhosted.org>


New submission from Akashkumar D Khunt <akashdkhunt at gmail.com>:

There is a typo in test_socket.py file where instead of ?testSecondCmsgTruncInData? function name is ?testSecomdCmsgTruncInData?.

----------
components: Tests
messages: 379763
nosy: adkhunt
priority: normal
severity: normal
status: open
title: Typo in test library for test_socket.py
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 27 11:59:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Oct 2020 15:59:08 +0000
Subject: [New-bugs-announce] [issue42173] Drop Solaris support
Message-ID: <1603814348.33.0.839225742612.issue42173@roundup.psfhosted.org>


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

In past years, very few Python core developers took care of the Solaris support. The latest significant Solaris enhancement was in 2018 with the addition of a new Solaris st_fstype attribute to os.stat(), in Python 3.7, by Jes?s Cea Avi?n (bpo-32659).

Another recent Solaris-related change is bpo-41687: "Fix implementation of sendfile to be compatible with Solaris".

On the Oracle side, there was an article about Python on Solaris in 2019:
"Future of Python on Solaris" by  Darren Moffat 
https://blogs.oracle.com/solaris/future-of-python-on-solaris

I now that Giampaolo Rodola cares of the Solaris support for his psutil project:
https://github.com/giampaolo/psutil/

It's unclear to me if Oracle still plans to maintain Solaris. The latest release was published 2 years ago. The Wikipedia article says: "While Oracle did have a large layoff of Solaris development engineering staff, development continues today of which Solaris 11.4 was released in 2018."
https://en.wikipedia.org/wiki/Solaris_(operating_system)

There is currently 25 open issues which could be closed if we drop the Solaris support.

See also the PEP 11 for the process.

I asked asked 4 years ago (in 2016) if Solaris support should/can be removed:
"OpenIndiana and Solaris support"
https://mail.python.org/archives/list/python-dev at python.org/message/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/

Python has no longer buildbot workers running on Solaris or a Solaris variant (OpenIndiana, Illumos, etc.).

I propose to drop the Solaris support in Python to reduce the maintenance burden.

Python has a few features specific to Solaris:

* st_fstype attribute of os.stat()
* select.devpoll and selectors.DevpollSelector
* time.CLOCK_HIGHRES constant
* stat.S_ISDOOR()
* tarfile: "Solaris extended header" (no need to remove this one)

Solaris has many names and variants:

* SunOS
* SRV4
* Solaris
* Illumos (still active in July 2020 at least)
* OpenSolaris: "On Friday, August 13, 2010, details started to emerge relating to the discontinuation of the OpenSolaris project and the pending release of a new closed-source, proprietary version of Solaris, Solaris 11." says Wikipedia
* OpenIndiana (latest release in 2020)

I'm not sure on how to process? Deprecate all Solaris-specific features in Python 3.10, make sure that Python 3.11 cannot be built on Solaris anymore, and drop the code in Python 3.12? Or drop everything as soon as possible in Python 3.10?

The alternative is to leave the code unchanged and let the code slowly die, as we did for other platforms like HP-UX and IRIX.

See also my notes on platforms supported by Python:
https://pythondev.readthedocs.io/platforms.html

Attached draft PR gives an idea on how much code can be removed if Solaris support is removed. A coase estimation is the removal of 700 lines:

 Doc/c-api/init.rst                           |   3 +-
 Doc/distutils/apiref.rst                     |   1 -
 Doc/library/gettext.rst                      |  10 +-
 Doc/library/os.rst                           |  12 +-
 Doc/library/platform.rst                     |   5 +-
 Doc/library/posix.rst                        |   8 +-
 Doc/library/sys.rst                          |   3 +-
 Doc/library/sysconfig.rst                    |   1 -
 Doc/library/time.rst                         |  13 +-
 Doc/using/unix.rst                           |   7 -
 Include/pyport.h                             |   5 -
 Lib/cgi.py                                   |   4 +-
 Lib/ctypes/test/test_byteswap.py             |   2 +-
 Lib/ctypes/util.py                           | 100 ++--------
 Lib/distutils/command/bdist.py               |   2 +-
 Lib/distutils/tests/support.py               |   2 +-
 Lib/distutils/tests/test_build_ext.py        |  21 --
 Lib/distutils/util.py                        |  11 --
 Lib/gettext.py                               |   3 -
 Lib/logging/handlers.py                      |   2 -
 Lib/platform.py                              |  27 +--
 Lib/sysconfig.py                             |  11 --
 Lib/test/fork_wait.py                        |   4 +-
 Lib/test/subprocessdata/fd_status.py         |   3 -
 Lib/test/test__locale.py                     |  24 ---
 Lib/test/test_asyncio/test_sendfile.py       |   6 -
 Lib/test/test_asyncore.py                    |   2 -
 Lib/test/test_cmd_line.py                    |   2 +-
 Lib/test/test_curses.py                      |   2 +-
 Lib/test/test_fileio.py                      |   2 +-
 Lib/test/test_importlib/import_/test_path.py |   2 +-
 Lib/test/test_locale.py                      |   2 +-
 Lib/test/test_os.py                          |  14 +-
 Lib/test/test_posix.py                       |   7 +-
 Lib/test/test_pty.py                         |   4 -
 Lib/test/test_selectors.py                   |   2 +-
 Lib/test/test_shutil.py                      |   2 +-
 Lib/test/test_socket.py                      |   4 -
 Lib/test/test_strftime.py                    |   3 +-
 Lib/test/test_sys.py                         |   2 +-
 Lib/uuid.py                                  |   5 -
 Modules/Setup                                |   4 -
 Modules/_ctypes/ctypes.h                     |   4 -
 Modules/_cursesmodule.c                      |   2 +-
 Modules/_multiprocessing/multiprocessing.h   |  15 --
 Modules/_posixsubprocess.c                   |  11 --
 Modules/errnomodule.c                        |  23 +--
 Modules/mathmodule.c                         |   2 +-
 Modules/posixmodule.c                        |  65 +-----
 Modules/signalmodule.c                       |   2 +-
 Modules/socketmodule.c                       |   7 -
 Modules/termios.c                            |   8 +-
 Modules/timemodule.c                         |   9 +-
 Python/bootstrap_hash.c                      |  17 +-
 Python/fileutils.c                           |   3 +-
 Python/import.c                              |   3 +-
 Tools/freeze/README                          |   5 -
 Tools/i18n/pygettext.py                      |   3 +-
 Tools/pynche/Main.py                         |   2 -
 Tools/pynche/README                          |   2 +-
 Tools/scripts/nm2def.py                      |   2 +-
 configure                                    | 285 +--------------------------
 configure.ac                                 | 101 +---------
 pyconfig.h.in                                |  19 +-
 setup.py                                     |  20 +-
 65 files changed, 91 insertions(+), 868 deletions(-)

----------
components: Interpreter Core
messages: 379767
nosy: giampaolo.rodola, jcea, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Drop Solaris support
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 27 12:32:31 2020
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 27 Oct 2020 16:32:31 +0000
Subject: [New-bugs-announce] [issue42174] shutil.get_terminal_size() returns
 0 when run in a pty
Message-ID: <1603816351.29.0.440046743483.issue42174@roundup.psfhosted.org>


New submission from Florian Bruhin <python.org at the-compiler.org>:

When shutil.get_terminal_size() is used in a PTY, the os.get_terminal_size() call can return (0, 0).

With the pty script from https://github.com/python/mypy/issues/8144#issue-537760245:

$ python3 t.py python3 -c 'import shutil; print(shutil.get_terminal_size())'        
os.terminal_size(columns=0, lines=0)

While the following cases *are* handled by returning the fallback:

- COLUMNS or lines being non-existent or 0
- os.get_terminal_size raising

The case of os.get_terminal_size() succeeding but returning (0, 0) should probably be handled the same way as well.

This e.g. affects mypy when run with pre-commit:
https://github.com/pre-commit/mirrors-mypy/issues/29

----------
components: Library (Lib)
messages: 379773
nosy: The Compiler, giampaolo.rodola, tarek
priority: normal
severity: normal
status: open
title: shutil.get_terminal_size() returns 0 when run in a pty
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 27 13:37:22 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 27 Oct 2020 17:37:22 +0000
Subject: [New-bugs-announce] [issue42175] long lines from interactive stdin
 are truncated
Message-ID: <1603820242.16.0.850917923233.issue42175@roundup.psfhosted.org>


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

this was originally pointed out in a comment on my youtube video here: https://youtu.be/Xf_82stIbB8


here's a reproduction:

1. produce 5000 characters of output: python3 -c 'print("a"*5000)'
2. copy that to the clipboard
3. run this: python3 -c 'import sys; print(len(sys.stdin.read()))'
4. paste
5. press enter
6. ^D

I get the following:

$ python3 -c 'import sys; print(len(sys.stdin.read()))'
...
4096

but I expect the value to be 5001 (+1 for the \n)

----------
messages: 379783
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: long lines from interactive stdin are truncated
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 27 14:52:25 2020
From: report at bugs.python.org (Boris Staletic)
Date: Tue, 27 Oct 2020 18:52:25 +0000
Subject: [New-bugs-announce] [issue42176] Valgrind reports "Conditional jump
 or move depends on uninitialised value(s)" in `PyUnicode_AsEncodedString`
 and `PyUnicode_Decode`
Message-ID: <1603824745.38.0.0631624355024.issue42176@roundup.psfhosted.org>


New submission from Boris Staletic <boris.staletic at gmail.com>:

When running valgrind on a C code that calls `PyUnicode_AsEncodedString` and `PyUnicode_Decode`, valgrind reports that there's a conditional jump based on uninitialized variable, if the encoding is "latin1".

I am able to replicate the error 100% of the time, on Ubuntu 20.04, with python 3.9.0 installed with pyenv. I also have repro'd the error in my CI (link below). Steps to repro:

1. docker run -it ubuntu:20.04 /bin/bash
2. apt update
3. apt install valgrind gcc build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev liblzma-dev python-openssl git
4. curl https://pyenv.run | bash
5. export PATH="/root/.pyenv/bin:$PATH"
6. eval "$(pyenv init -)"
7. PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install 3.9.0
8. Take the attached C file.
9. gcc -ggdb3 -I/root/.pyenv/versions/3.9.0/include/python3.9 -L/root/.pyenv/versions/3.9.0/lib test2.c -lpython3.9
10. LD_LIBRARY_PATH=/root/.pyenv/versions/3.9.0/lib/ PYTHONMALLOC=malloc valgrind ./a.out

Valgrind output:

==22783== Conditional jump or move depends on uninitialised value(s)
==22783==    at 0x49ABE64: PyUnicode_Decode (unicodeobject.c:3443)
==22783==    by 0x49ABE64: PyUnicode_Decode (unicodeobject.c:3398)
==22783==    by 0x109251: main (test2.c:5)
==22783==
==22783== Conditional jump or move depends on uninitialised value(s)
==22783==    at 0x499A294: PyUnicode_AsEncodedString (unicodeobject.c:3732)
==22783==    by 0x499A294: PyUnicode_AsEncodedString (unicodeobject.c:3688)
==22783==    by 0x10926D: main (test2.c:6)


CI log: https://dev.azure.com/borisstaletic/3ce92110-caa5-4c49-b8c3-44a433da676b/_apis/build/builds/1338/logs/6
Repository for testing the bug: https://github.com/bstaletic/ycmd/tree/python-error

----------
components: Interpreter Core
files: test.c
messages: 379790
nosy: bstaletic
priority: normal
severity: normal
status: open
title: Valgrind reports "Conditional jump or move depends on uninitialised value(s)" in `PyUnicode_AsEncodedString` and `PyUnicode_Decode`
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file49542/test.c

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

From report at bugs.python.org  Tue Oct 27 16:43:09 2020
From: report at bugs.python.org (Orian Zinger)
Date: Tue, 27 Oct 2020 20:43:09 +0000
Subject: [New-bugs-announce] [issue42177] Improving KeyError exception
Message-ID: <1603831389.37.0.739931289382.issue42177@roundup.psfhosted.org>


New submission from Orian Zinger <zinger777 at gmail.com>:

Hi all,

As a Python developer, I encountered lots of blurry exception messages in the product logs such as:
<time and date> <process name> <log severity> Failed to do something. Exception: 'some key'

I believe printing the key name without explaining the exception itself is bad (explicit is better than implicit).

Thus, after forking the repository, I added a short explanation about the Exception.
Now, it looks like:

>>> try:
...     {}['some key']
... except Exception as e:
...     print(e)
... 
Missing key: some key

I'm a newbie in a contribution to CPython, so please let me know if the idea behind my commit is good. If not, please explain how can I improve my commit so it'll be pulled later to the main branch.

https://github.com/zingero/cpython/commit/8c9e5d9e16296cee1f3ec05638dd6989dae8b811

Regards,
Orian.

----------
messages: 379801
nosy: zingero
priority: normal
severity: normal
status: open
title: Improving KeyError exception
type: enhancement

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

From report at bugs.python.org  Tue Oct 27 16:52:33 2020
From: report at bugs.python.org (Charles McMarrow)
Date: Tue, 27 Oct 2020 20:52:33 +0000
Subject: [New-bugs-announce] [issue42178] failed pickle hangs python on exit
 in CMD.exe only
Message-ID: <1603831953.96.0.174038023621.issue42178@roundup.psfhosted.org>


New submission from Charles McMarrow <charles.mcmarrow.4 at gmail.com>:

This bug only happens for me in Windows 10 when using cmd.exe. This bug does not happen IDLE. It sometimes happens in PowerShell. 

I ran mp_hang.py
with 
3.9.0 hangs on cmd/powershell
3.8.6 hangs on cmd
3.8.5 hangs on cmd/powershell
Microsoft Windows [Version 10.0.19041.572]

3.8.6 error
```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\yoshi\AppData\Local\Programs\Python\Python38\lib\multiprocessing\spawn.py", line 102, in spawn_main
    source_process = _winapi.OpenProcess(
OSError: [WinError 87] The parameter is incorrect
```

----------
components: Windows
files: mp_hang.py
messages: 379803
nosy: charles.mcmarrow.4, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: failed pickle hangs python on exit in CMD.exe only
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49543/mp_hang.py

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

From report at bugs.python.org  Wed Oct 28 04:31:31 2020
From: report at bugs.python.org (Vladimir Ryabtsev)
Date: Wed, 28 Oct 2020 08:31:31 +0000
Subject: [New-bugs-announce] [issue42179] Clarify chaining exceptions in
 tutorial/errors.rst
Message-ID: <1603873891.9.0.500762071742.issue42179@roundup.psfhosted.org>


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

A new section has been added to the page as a result of https://bugs.python.org/issue37826. The change: https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dcf59392

The wording it uses (in the beginning of section 8.5), defines chaining as setting __cause__ attribute in an exception, and later states that "Exception chaining happens automatically when an exception is raised inside an exception handler or finally section". This may lead the reader to a wrong idea that re-raising an exception without "from" in "except" and "finally" automatically sets __cause__. In reality it sets only __context__ attribute, which is similar concept to __cause__, but work a bit differently, as explained in library/exceptions.rst. I suggest to mention that difference and provide a link to the main article.

----------
assignee: docs at python
components: Documentation
messages: 379823
nosy: Vladimir Ryabtsev, docs at python
priority: normal
severity: normal
status: open
title: Clarify chaining exceptions in tutorial/errors.rst
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Oct 28 07:08:34 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Wed, 28 Oct 2020 11:08:34 +0000
Subject: [New-bugs-announce] [issue42180] Missing a plural in
 library/functions
Message-ID: <1603883314.74.0.667097394746.issue42180@roundup.psfhosted.org>


New submission from Rafael Fontenelle <rffontenelle at gmail.com>:

Missing plural in the start of the following sentence from library/functions:

"The optional argument *flags* and *dont_inherit* controls which :ref:`compiler options <ast-compiler-flags>` should be activated and which :ref:`future features <future>` should be allowed."

This was introduced in bpo-40484, probably by accident.

Link to source code: https://github.com/python/cpython/blob/master/Doc/library/functions.rst#L262

----------
messages: 379827
nosy: rffontenelle
priority: normal
severity: normal
status: open
title: Missing a plural in library/functions
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 28 10:18:31 2020
From: report at bugs.python.org (Joachim)
Date: Wed, 28 Oct 2020 14:18:31 +0000
Subject: [New-bugs-announce] [issue42181] describe
 PyEval_CallObjectWithKeywords and its replacement
Message-ID: <1603894711.43.0.142721480752.issue42181@roundup.psfhosted.org>


New submission from Joachim <j.wuttke at fz-juelich.de>:

The current 3.9 docs do not describe PyEval_CallObjectWithKeywords, among other PyEval_CallObject* functions.

Yes, I know, these functions are deprecated. But they are still part of the API; they ought to be documented.

Rather, given that they are deprecated, there is more need than ever to document them: The documentation should specify when they have been deprecated, until then they are guaranteed to be supported, and most importantly, how they are to be replaced.

Fulltext search leads me to the 3.9 Changelog that says: ?PyEval_CallFunction, PyEval_CallMethod and PyEval_CallObjectWithKeywords are deprecated. Use PyObject_Call() and its variants instead.? This is far not enough. As a maintainer of 3rd-party code with no knowledge of and no interest in the Python C API, I do not want to spend half a day on finding out which variant to use, and how argument lists differ.

----------
components: C API
messages: 379828
nosy: j5w6, jdemeyer
priority: normal
severity: normal
status: open
title: describe PyEval_CallObjectWithKeywords and its replacement
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 28 11:28:27 2020
From: report at bugs.python.org (Ken Jin)
Date: Wed, 28 Oct 2020 15:28:27 +0000
Subject: [New-bugs-announce] [issue42182] 3.10 Documentation Not
 Hyperlinking Some Methods
Message-ID: <1603898907.29.0.300729601022.issue42182@roundup.psfhosted.org>


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

Some ``:meth:`` markups are not being hyperlinked at all, while some are. This only occurs for Python 3.10. This also seems related to https://bugs.python.org/issue42042.

Eg. 
For 3.9, https://docs.python.org/3.9/library/stdtypes.html#truth-value-testing:
``__bool__``, ``__len__`` are hyperlinked.

For 3.10, https://docs.python.org/3.10/library/stdtypes.html#truth-value-testing:
``__bool__``, ``__len__`` are not hyperlinked.

This occurs throughout the documentation, but it doesn't seem to consistently happen. For example, in https://docs.python.org/3.10/library/stdtypes.html#contextmanager.__exit__ , ``__exit__`` is hyperlinked, but right below that section, the other ``__exit__``s are not. This is puzzling since their markup both uses the same :meth:`__exit__`.

I'm not able to locally reproduce this using Sphinx 2.4.0. I don't know which version exactly of Sphinx this regression occured.

----------
assignee: docs at python
components: Documentation
messages: 379829
nosy: docs at python, kj
priority: normal
severity: normal
status: open
title: 3.10 Documentation Not Hyperlinking Some Methods
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 28 12:59:24 2020
From: report at bugs.python.org (Gobot1234)
Date: Wed, 28 Oct 2020 16:59:24 +0000
Subject: [New-bugs-announce] [issue42183] Stack overflow error with
 asyncio.all_tasks and wait_for
Message-ID: <1603904364.33.0.601096284613.issue42183@roundup.psfhosted.org>


New submission from Gobot1234 <gobot1234yt at gmail.com>:

Using asyncio.wait_for and asyncio.all_tasks in combination causes a stack overflow error. 

Code to reproduce issue:
```
import asyncio

async def func():
    return asyncio.all_tasks()

async def main():
    print(await asyncio.wait_for(func(), timeout=10))

asyncio.run(main())
```

I'm not too sure how far back this goes but I've managed to reproduce it on sys.version_info(major=3, minor=8, micro=0, releaselevel='final', serial=0) and sys.version_info(major=3, minor=9, micro=0, releaselevel='final', serial=0).

----------
components: asyncio
messages: 379837
nosy: Gobot1234, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Stack overflow error with asyncio.all_tasks and wait_for
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 28 14:07:15 2020
From: report at bugs.python.org (Adam Merchant)
Date: Wed, 28 Oct 2020 18:07:15 +0000
Subject: [New-bugs-announce] [issue42184] pdb exits unexpectedly when
 calling args
Message-ID: <1603908435.7.0.582462540621.issue42184@roundup.psfhosted.org>


New submission from Adam Merchant <xgenadam at gmail.com>:

When an objects __repr__ or __str__ methods return None a TypeError is raised. However if this object is passed to a function and `args` is called from within pdb, pdb will immediately exit.

Attached to this is bug_example.py which contains a simple example of how to reproduce this.

Depending on circumstances this can make debugging difficult.

exact python version that this happened with:
Python 3.6.11

----------
files: bug_example.py
messages: 379838
nosy: xgenadam
priority: normal
severity: normal
status: open
title: pdb exits unexpectedly when calling args
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49546/bug_example.py

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

From report at bugs.python.org  Wed Oct 28 14:17:34 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 28 Oct 2020 18:17:34 +0000
Subject: [New-bugs-announce] [issue42185] class body bytecode uses less
 efficient *_NAME opcodes
Message-ID: <1603909054.81.0.403875611557.issue42185@roundup.psfhosted.org>


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

The opcodes generated for the closure defining a class body looks like they might be suboptimal.  It seems stuck using the generic LOAD_NAME and STORE_NAME opcodes rather than the LOAD_GLOBAL and STORE_FAST and friends as one would expect and as happens within a normal function closure.

If true and the normal optimization pass (which I believe is done by `compiler.c` `compiler_nameop()` if i'm understanding this area of the code I don't know very well correctly...?) is not happening, it _appears_ maybe to be due to the `PyST_GetScope` call not currently having a way to represent this situation rather than being in a normal function?

I tried searching for an open issue on this but was at a loss of what to search for.  semi-related concepts might be found in:
 https://bugs.python.org/issue34750 - "locals().update doesn't work in Enum body, even though direct assignment to locals() does"
 https://bugs.python.org/issue10399 - "AST Optimization: inlining of function calls"
 https://bugs.python.org/issue9226 - "errors creating classes inside a closure"

None of those is really the same though.  if there are other filed issues regarding this, feel free to link to them in comments.

If this can be improved as it has been for function bodies already, it should be a measurable improvement to CPython startup time and/or import time.  Especially on larger programs and things with a lot of generated code full of classes.

```
>>> import dis
>>> klass_def = '''
... class Klassy:
...   pinky = 'brain'
... def Funktion(castle_argh):
...   __module__ = __name__
...   __qualname__ = 'not Klassy'
...   pinky = 'brain'
... '''
>>> dis.dis(compile(klass_def, '<Hi mom!>', 'exec'))
  2           0 LOAD_BUILD_CLASS
              2 LOAD_CONST               0 (<code object Klassy at 0x7f62f4f6e3a0, file "<Hi mom!>", line 2>)
              4 LOAD_CONST               1 ('Klassy')
              6 MAKE_FUNCTION            0
              8 LOAD_CONST               1 ('Klassy')
             10 CALL_FUNCTION            2
             12 STORE_NAME               0 (Klassy)

  4          14 LOAD_CONST               2 (<code object Funktion at 0x7f62f4f7fa80, file "<Hi mom!>", line 4>)
             16 LOAD_CONST               3 ('Funktion')
             18 MAKE_FUNCTION            0
             20 STORE_NAME               1 (Funktion)
             22 LOAD_CONST               4 (None)
             24 RETURN_VALUE

Disassembly of <code object Klassy at 0x7f62f4f6e3a0, file "<Hi mom!>", line 2>:
  2           0 LOAD_NAME                0 (__name__)
              2 STORE_NAME               1 (__module__)
              4 LOAD_CONST               0 ('Klassy')
              6 STORE_NAME               2 (__qualname__)

  3           8 LOAD_CONST               1 ('brain')
             10 STORE_NAME               3 (pinky)
             12 LOAD_CONST               2 (None)
             14 RETURN_VALUE

Disassembly of <code object Funktion at 0x7f62f4f7fa80, file "<Hi mom!>", line 4>:
  5           0 LOAD_GLOBAL              0 (__name__)
              2 STORE_FAST               1 (__module__)

  6           4 LOAD_CONST               1 ('not Klassy')
              6 STORE_FAST               2 (__qualname__)

  7           8 LOAD_CONST               2 ('brain')
             10 STORE_FAST               3 (pinky)
             12 LOAD_CONST               0 (None)
             14 RETURN_VALUE
```

----------
components: Interpreter Core
messages: 379839
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
stage: needs patch
status: open
title: class body bytecode uses less efficient *_NAME opcodes
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 28 16:42:28 2020
From: report at bugs.python.org (Yilei Yang)
Date: Wed, 28 Oct 2020 20:42:28 +0000
Subject: [New-bugs-announce] [issue42186] unittest overrides more serious
 warnings filter added before unittest.main()
Message-ID: <1603917748.58.0.497118511027.issue42186@roundup.psfhosted.org>


New submission from Yilei Yang <yileiyang9 at gmail.com>:

Because unittest adds a `default` filter before tests run, other warnings filters are overridden if added before.

Ideally, unittest should not make the warnings less serious, e.g. if there is already an 'error' filter that raises exception, it shouldn't "downgrade" to 'default' that simply prints.

The following example, using lib.a_function() raises exception in a regular program, but the unit test passes:

$ cat lib.py
import warnings
class MyWarning(UserWarning):
    pass
warnings.filterwarnings('error', category=MyWarning)
def a_function():
  warnings.warn('Do not use.', MyWarning)

$ cat lib_test.py
import unittest
import lib
class TestLib(unittest.TestCase):
    def test_function(self):
        lib.a_function()
if __name__ == '__main__':
    unittest.main()

$ python -m unittest -v lib_test
test_function (lib_test.TestLib) ... lib.py:6: MyWarning: Do not use.
  warnings.warn('Do not use.', MyWarning)
ok

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

OK

$ python
>>> import lib
>>> lib.a_function()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lib.py", line 6, in a_function
    warnings.warn('Do not use.', MyWarning)
lib.MyWarning: Do not use.

----------
components: Library (Lib)
messages: 379843
nosy: yilei
priority: normal
severity: normal
status: open
title: unittest overrides more serious warnings filter added before unittest.main()
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/issue42186>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:57:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 28 Oct 2020 20:57:30 +0000
Subject: [New-bugs-announce] [issue42187] Deprecating / removing
 token.ISTERMINAL/ISNONTERMINAL
Message-ID: <1603918650.53.0.755514465217.issue42187@roundup.psfhosted.org>


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

Since the parser & symbol modules are removed, there is no real use case for ISTERMINAL/ISNONTERMINAL since the only input that contains grammar symbols is the input of the tokenize, which all its outputs are terminals. Which restricts the practicality of token.ISTERMINAL/ISNONTERMINAL. I'd propose we either deprecate them or remove them completely.

Search over the most populer PyPI packages (a set of 4k) showed there are only 2 projects that uses these functions, which all cases coupled with the parser module.
pyglet-1.5.7/pyglet/text/formats/attributed.py
133:        if token.ISNONTERMINAL(node[0]):
gdata-2.0.18/tests/coverage.py
328:        if token.ISNONTERMINAL(tree[0]):

If we are going through a deprecation period, I will also propose to remove ISEOF, since it can be easily replaced and very under used. The only project that uses token.ISEOF in my dataset is asttokens, which I would say all cases there can be easily replaced tok.type == token.EOF

asttokens-2.0.4/asttokens/mark_tokens.py
105:           not token.ISEOF(t.type)):

Also, these functions are originally reflections of C macros used in the past, and since they are not used right now, we can also remove those macros.

I have no opinions about the token.NT_OFFSET though, but there are a couple of occurrences so we might keep that? 
Paste-3.4.4/paste/util/PySourceColor.py
205:ARGS = token.NT_OFFSET + 1
206:DOUBLECOMMENT = token.NT_OFFSET + 2

ipython-7.18.1/IPython/utils/PyColorize.py
54:_KEYWORD = token.NT_OFFSET + 1
55:_TEXT    = token.NT_OFFSET + 2

----------
keywords: 3.4regression
messages: 379844
nosy: BTaskaya, gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Deprecating / removing token.ISTERMINAL/ISNONTERMINAL

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

From report at bugs.python.org  Wed Oct 28 20:40:06 2020
From: report at bugs.python.org (Colin)
Date: Thu, 29 Oct 2020 00:40:06 +0000
Subject: [New-bugs-announce] [issue42188] forkserver not reused in child
 processes
Message-ID: <1603932006.71.0.807048888281.issue42188@roundup.psfhosted.org>


New submission from Colin <cjphlo94 at gmail.com>:

The docstring on Forkserver.ensure_running states that a child process will use the forkserver process started by its parent:

"""
Make sure that a fork server is running.

This can be called from any process.  Note that usually a child
process will just reuse the forkserver started by its parent, so
ensure_running() will do nothing.
"""

Link to definition: https://github.com/python/cpython/blob/master/Lib/multiprocessing/forkserver.py#L105

That is not the behavior that I am seeing, however. I'm seeing each child (that start a process itself) will first spawn a *new* forkserver.

----------
components: Library (Lib)
files: test.py
messages: 379851
nosy: cchomey
priority: normal
severity: normal
status: open
title: forkserver not reused in child processes
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49547/test.py

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

From report at bugs.python.org  Wed Oct 28 21:53:35 2020
From: report at bugs.python.org (Robert O'Callahan)
Date: Thu, 29 Oct 2020 01:53:35 +0000
Subject: [New-bugs-announce] [issue42189] copy.deepcopy() no longer works on
 platform.uname_result objects
Message-ID: <1603936415.14.0.266024580779.issue42189@roundup.psfhosted.org>


New submission from Robert O'Callahan <rocallahan at gmail.com>:

Starting from Python 3.9, copy.deepcopy can't copy a platform.uname_result object.

```
Python 3.9.0 (default, Oct  6 2020, 00:00:00) 
[GCC 10.2.1 20200826 (Red Hat 10.2.1-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> import copy
>>> u = platform.uname()
>>> print(u)
uname_result(system='Linux', node='localhost.localdomain', release='5.8.16-300.fc33.x86_64', version='#1 SMP Mon Oct 19 13:18:33 UTC 2020', machine='x86_64')
>>> v = copy.deepcopy(u)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.9/copy.py", line 172, in deepcopy
    y = _reconstruct(x, memo, *rv)
  File "/usr/lib64/python3.9/copy.py", line 264, in _reconstruct
    y = func(*args)
  File "/usr/lib64/python3.9/copyreg.py", line 91, in __newobj__
    return cls.__new__(cls, *args)
TypeError: <lambda>() takes 6 positional arguments but 7 were given
```

Looks similar to issue 42163 but I guess it might need to be fixed differently.

This has broken building Intel's Xed library, which uses a Python-based build system: https://github.com/intelxed/mbuild

----------
components: Library (Lib)
messages: 379853
nosy: rocallahan
priority: normal
severity: normal
status: open
title: copy.deepcopy() no longer works on platform.uname_result objects
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Oct 29 01:07:31 2020
From: report at bugs.python.org (Kevin Shweh)
Date: Thu, 29 Oct 2020 05:07:31 +0000
Subject: [New-bugs-announce] [issue42190] global declarations affect too
 much inside exec or compile
Message-ID: <1603948051.35.0.0996569389685.issue42190@roundup.psfhosted.org>


New submission from Kevin Shweh <kevin.shweh at gmail.com>:

A global declaration inside a function is only supposed to affect assignments inside that function, but in code executed with exec, a global declaration affects assignments outside the function:

>>> gdict = {}
>>> ldict = {}
>>> exec('x = 1', gdict, ldict)
>>> 'x' in gdict
False
>>> 'x' in ldict
True
>>> 
>>> gdict = {}
>>> ldict = {}
>>> exec('''
... x = 1
... def f(): global x''', gdict, ldict)
>>> 'x' in gdict
True
>>> 'x' in ldict
False

Here, we can see that the presence of a "global x" declaration inside f causes the "x = 1" outside of f to assign to globals instead of locals. This also affects code objects compiled with compile().

----------
components: Interpreter Core
messages: 379855
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: global declarations affect too much inside exec or compile
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 29 03:45:26 2020
From: report at bugs.python.org (Aschwin)
Date: Thu, 29 Oct 2020 07:45:26 +0000
Subject: [New-bugs-announce] [issue42191] lib.argparse._check_value() using
 repre instead of str
Message-ID: <1603957526.8.0.0927596859344.issue42191@roundup.psfhosted.org>


New submission from Aschwin <aschwin at vanderwoude.info>:

When using a custom type in add_argument(), the error message on an incorrect value uses repr instead of str, which looks ugly.

Example code:

login2account = {
    c.account.login: c.account for c in self.admin.get_accounts()
}

action_add_parser.add_argument(
    "--user", 
    dest="user",
    type=lambda x: login2account.get(x, x),
    choices=list(login2account.values()), 
    help="Login name of the user",
)


When using an unknown user, the output is something alike:
   action add: error: argument --assignee: invalid choice: karen (choose from <Account(login=john)>, <Account(login=peter)>)

The culprit is the following line in lib.argparse._check_value():

    args = {'value': value,
            'choices': ', '.join(map(repr, action.choices))}

Which should be the following for prettier output:

    args = {'value': value,
            'choices': ', '.join(map(str, action.choices))}

----------
components: Library (Lib)
messages: 379856
nosy: avdwoude
priority: normal
severity: normal
status: open
title: lib.argparse._check_value() using repre instead of str
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 29 05:16:07 2020
From: report at bugs.python.org (Martin Gfeller)
Date: Thu, 29 Oct 2020 09:16:07 +0000
Subject: [New-bugs-announce] [issue42192] Python Windows .exe Installer
 ignores /TargetDir if there is an existing installation
Message-ID: <1603962967.32.0.325420802039.issue42192@roundup.psfhosted.org>


New submission from Martin Gfeller <martin.gfeller at swisscom.com>:

I would like to install Python in a new location, completely separate and not affecting an existing installation of the same version. 

Despite I use /TargetDir=newdir, the installer goes into the "Modify Setup" dialog. If I chose "Modify", it shows my TargetDir read-only in the Customize installation location, but then modifies the original installation. 

If I run it with /passive or /quiet, it also modifies the existing installation instead of creating a new one at /TargetDir (doing nothing, since there is nothing to modify).

If I choose repair at the prompt, it installs the Debug version (only!) into the TargetDir, with no library files except venv\scripts\nt (containing the debug .exe). 

It seems the installer checks whether there is an existing installation based on the registry (or by other means such peeking into the default installation directory). If there is an existing installation, the  /TargetDir seems to be ignored, except for the peculiar repair installation of the debug build (which I never asked for).

I believe this to be a bug in the installer; however if ignoring the /TargetDir once an existing installation is found (which I do not find desirable), it should be documented. 

The /TARGETDIR option of the old .msi installer didn't have this problem, it would reliably install into the target dir.

----------
components: Installation, Windows
messages: 379859
nosy: Martin.Gfeller, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python Windows .exe Installer ignores /TargetDir if there is an existing installation
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 29 06:42:52 2020
From: report at bugs.python.org (flying sheep)
Date: Thu, 29 Oct 2020 10:42:52 +0000
Subject: [New-bugs-announce] [issue42193] Improve socket.bind error message
Message-ID: <1603968172.16.0.632211666249.issue42193@roundup.psfhosted.org>


New submission from flying sheep <flying-sheep at web.de>:

In the end of my stack trace, I just see

      File "...", line 174, in bind_sockets
        sock.bind(sockaddr)
    OSError: [Errno 99] Cannot assign requested address

It would be useful if it would tell me which socket that was in the error message.

----------
messages: 379865
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Improve socket.bind error message

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

From report at bugs.python.org  Thu Oct 29 07:54:09 2020
From: report at bugs.python.org (shangxiao)
Date: Thu, 29 Oct 2020 11:54:09 +0000
Subject: [New-bugs-announce] [issue42194] BooleanOptionalAction missing "New
 in version 3.9"
Message-ID: <1603972449.31.0.552627573436.issue42194@roundup.psfhosted.org>


New submission from shangxiao <shang.xiao.sanders at gmail.com>:

The section that describes BooleanOptionalAction just requires a "New in version 3.9" tag

----------
assignee: docs at python
components: Documentation
messages: 379867
nosy: docs at python, shangxiao
priority: normal
severity: normal
status: open
title: BooleanOptionalAction missing "New in version 3.9"
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 29 08:25:19 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Thu, 29 Oct 2020 12:25:19 +0000
Subject: [New-bugs-announce] [issue42195] Inconsistent __args__ between
 typing.Callable and collections.abc.Callable
Message-ID: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

The two ways of getting a parametrised Callable have inconsistent __args__:

    >>> import collections.abc, typing
    >>> typing.Callable[[int, int], int].__args__
    (int, int, int)
    >>> collections.abc.Callable[[int, int], int].__args__
    ([int, int], int)

I discovered this while working on PEP 585 support in Hypothesis [1], where it is easy enough to work around but carries a potentially serious performance cost - the list means we cannot use the type as a cache key for non-`...` argument types.  

https://bugs.python.org/issue40494 and https://bugs.python.org/issue40398 may be related.

[1] https://github.com/HypothesisWorks/hypothesis/pull/2653

----------
components: Library (Lib)
messages: 379869
nosy: Zac Hatfield-Dodds, gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistent __args__ between typing.Callable and collections.abc.Callable
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Oct 29 09:39:00 2020
From: report at bugs.python.org (shakir_juolay)
Date: Thu, 29 Oct 2020 13:39:00 +0000
Subject: [New-bugs-announce] [issue42196] Python Windows Installation Error
 0x800705aa
Message-ID: <1603978740.79.0.0573376832754.issue42196@roundup.psfhosted.org>


New submission from shakir_juolay <shakir_juolay at yahoo.com>:

I have recently changed my laptop and my Admin copied everything from D:\Users\sjuolay folder from the old laptop to new laptop. Both Windows 10. I had Python 3.8 64bit on the old laptop. I am trying to install Python 3.9 64bit on my new laptop. But I failed with error 0x800705aa. Attached is the log file.

Also Windows CMD is behaving strange. It does not throw any error on 'python' command but does nothing. It throws error on 'py' command.

Microsoft Windows [Version 10.0.19041.546]
(c) 2020 Microsoft Corporation. All rights reserved.

D:\Users\sjuolay>python

D:\Users\sjuolay>py
'py' is not recognized as an internal or external command,
operable program or batch file.

D:\Users\sjuolay>

----------
components: Installation
files: Pyhon39InstallLog.txt
messages: 379873
nosy: shakir_juolay
priority: normal
severity: normal
status: open
title: Python Windows Installation Error 0x800705aa
versions: Python 3.9
Added file: https://bugs.python.org/file49548/Pyhon39InstallLog.txt

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

From report at bugs.python.org  Thu Oct 29 10:16:41 2020
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 29 Oct 2020 14:16:41 +0000
Subject: [New-bugs-announce] [issue42197] Disable automatic update of frame
 locals during tracing
Message-ID: <1603981001.04.0.667888856285.issue42197@roundup.psfhosted.org>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Right now, when a debugger is active, the number of local variables can affect the tracing speed quite a lot.

For instance, having tracing setup in a program such as the one below takes 4.64 seconds to run, yet, changing all the variables to have the same name -- i.e.: change all assignments to `a = 1` (such that there's only a single variable in the namespace), it takes 1.47 seconds (in my machine)... the higher the number of variables, the slower the tracing becomes.

```
import time
t = time.time()

def call():
    a = 1
    b = 1
    c = 1
    d = 1
    e = 1
    f = 1

def noop(frame, event, arg):
    return noop

import sys
sys.settrace(noop)

for i in range(1_000_000):
    call()

print('%.2fs' % (time.time() - t,))
```

This happens because `PyFrame_FastToLocalsWithError` and `PyFrame_LocalsToFast` are called inside the `call_trampoline` (https://github.com/python/cpython/blob/master/Python/sysmodule.c#L946).

So, I'd like to simply remove those calls.

Debuggers can call  `PyFrame_LocalsToFast` when needed -- otherwise mutating non-current frames doesn't work anyways. As a note, pydevd already has such a call: https://github.com/fabioz/PyDev.Debugger/blob/0d4d210f01a1c0a8647178b2e665b53ab113509d/_pydevd_bundle/pydevd_save_locals.py#L57 and PyPy also has a counterpart.

As for `PyFrame_FastToLocalsWithError`, I don't really see any reason to call it at all.

i.e.: something as the code below prints the `a` variable from the `main()` frame regardless of that and I checked all pydevd tests and nothing seems to be affected (it seems that accessing f_locals already does this: https://github.com/python/cpython/blob/cb9879b948a19c9434316f8ab6aba9c4601a8173/Objects/frameobject.c#L35, so, I don't see much reason to call it at all).

```
def call():
    import sys
    frame = sys._getframe()
    print(frame.f_back.f_locals)
   
def main():
    a = 1
    call()
   
if __name__ == '__main__':
    main()
```

So, the idea is removing those lines (I expect that I'll be able to provide a pull request for this).

----------
components: Interpreter Core
messages: 379874
nosy: fabioz
priority: normal
severity: normal
status: open
title: Disable automatic update of frame locals during tracing
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 29 11:39:44 2020
From: report at bugs.python.org (Ken Jin)
Date: Thu, 29 Oct 2020 15:39:44 +0000
Subject: [New-bugs-announce] [issue42198] Clean up docs for Union and
 GenericAlias
Message-ID: <1603985984.49.0.749762775371.issue42198@roundup.psfhosted.org>


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

This is an umbrella issue to clean up docs for Union and GenericAlias. To-do (not in order):

1. Update links in typing, subscription and union to point to GenericAlias.

2. Park GenericAlias and Union under a new section 'Type Annotation Types' in stdtypes for 3.10. The reason is to follow with the rest of the stdtypes' doc convention.

3. Consistency nitpicks for Union's docs.

----------
assignee: docs at python
components: Documentation
messages: 379876
nosy: docs at python, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Clean up docs for Union and GenericAlias
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Oct 29 17:22:06 2020
From: report at bugs.python.org (Maxwell Bernstein)
Date: Thu, 29 Oct 2020 21:22:06 +0000
Subject: [New-bugs-announce] [issue42199] bytecode_helper
 assertNotInBytecode fails too eagerly
Message-ID: <1604006526.43.0.914046612592.issue42199@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

assertNotInBytecode should only fail if:

* the instr matches and the arg is unspecified, or
* the instr matches, the arg is specified, and the arg matches

But right now it fails in a third case because of the dangling self.fail() call. The self.fail() call should be moved into the `if`/`elif`.

----------
components: Tests
messages: 379885
nosy: tekknolagi
priority: normal
severity: normal
status: open
title: bytecode_helper assertNotInBytecode fails too eagerly
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/issue42199>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:24:05 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Fri, 30 Oct 2020 02:24:05 +0000
Subject: [New-bugs-announce] [issue42200] Support TLS 1.3 half-closed
 connections
Message-ID: <1604024645.33.0.358615043309.issue42200@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

(apologies if this was raised before, I couldn't find it in bugs, mailing lists or discourse).
(also apologies if I misunderstood something about the protocol)

Up to an including TLS 1.2, a single close notify terminates both upstream and downstream; Starting with TLS 1.3 there are separate close notify alerts for upstream and downstream.

This means that it's possible to have a TLS connection in half-closed state, e.g. to send "GET / HTTP xx; close notify" and then wait for the server response.

Today, that's not possible, at least in asyncio, as evidenced by https://bugs.python.org/issue39951 
(I did not check synchronous wrapped sockets)

----------
assignee: christian.heimes
components: SSL
messages: 379908
nosy: Dima.Tisnek, christian.heimes
priority: normal
severity: normal
status: open
title: Support TLS 1.3 half-closed connections
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 30 02:40:34 2020
From: report at bugs.python.org (=?utf-8?b?0JTQsNC90LjQuNC7INCb0Y/RhdC+0LI=?=)
Date: Fri, 30 Oct 2020 06:40:34 +0000
Subject: [New-bugs-announce] [issue42201] Priority queue realization issue
Message-ID: <1604040034.11.0.135907036135.issue42201@roundup.psfhosted.org>


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

In Priority queue realization in docs https://docs.python.org/3/library/heapq.html there is no appointments that priority can be equal and the task can have different type. For example, if you store number of graph node in your priority queue, than it is possible to get "TypeError: '<' not supported between instances of 'int' and 'str'", because inside heappop there is comparison between elements, and if the fist elements the same, than it compare tasks, which can be tagged as removed and has '<removed-task>' value as opposed to number of node, which is int.

----------
assignee: docs at python
components: Documentation
messages: 379922
nosy: docs at python, dupeljan
priority: normal
severity: normal
status: open
title: Priority queue realization issue
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 30 02:47:15 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 30 Oct 2020 06:47:15 +0000
Subject: [New-bugs-announce] [issue42202] Optimize function annotation
Message-ID: <1604040435.44.0.369975398522.issue42202@roundup.psfhosted.org>


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

Look this example:

code:

```
# code
def foo(x: int, /, y, *, z: float) -> Hoge:
    pass

# dis
 2          12 LOAD_CONST               2 ('int')
            14 LOAD_CONST               3 ('float')
            16 LOAD_CONST               4 ('Hoge')
            18 LOAD_CONST               5 (('x', 'z', 'return'))
            20 BUILD_CONST_KEY_MAP      3
            22 LOAD_CONST               6 (<code object foo at ...>)
            24 LOAD_CONST               7 ('foo')
            26 MAKE_FUNCTION            4 (annotations)
            28 STORE_NAME               2 (foo) 
```

Four `LOAD_CONST` and `BUILD_CONST_KEY_MAP` are used to generate annotation dict. This makes program load slow and eat more memory.

Annotation information can be stored in some compact form. And creating annotation dict can be postponed to when `func.__annotation__` is accessed.

Ideas for the compact form:

1. Tuple.
   In above example, `('int', None, 'float', 'Hoge')` can be used. None means no annotation for the 'y' parameter.

2. Serialize into str or bytes.
   JSON like format can be used, like `x:int,z:float;Hoge`. Compact. But the string/bytes has lower chance to be shared with other constants in same module.

----------
components: Interpreter Core
messages: 379923
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize function annotation
type: resource usage
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 30 03:44:09 2020
From: report at bugs.python.org (john ryan)
Date: Fri, 30 Oct 2020 07:44:09 +0000
Subject: [New-bugs-announce] [issue42203] Unexpected behaviour NameError:
 name 'open' is not defined
Message-ID: <1604043849.8.0.342211011492.issue42203@roundup.psfhosted.org>


New submission from john ryan <jryan at tactiq.co.uk>:

My test environment runs Ubuntu 18.04 in a virtualbox hosted on Windows 8.1 and Python executes within a venv running Python 3.9.0 (Python 3.9.0 (default, Oct 26 2020, 09:02:51) 
[GCC 7.5.0] on linux

Running a test with unittest.IsolatedAsyncioTestCase my code hung so I hit ctrl-C twice to stop it and got the below traceback.

The really odd behaviour is that open is reported as not defined.

The behaviour is repeatable in my test, but I do not know how to produce a simple test case. I do not know what the issue is with my code.


 ^C^CTraceback (most recent call last):
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/async_case.py", line 158, in run
    return super().run(result)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/case.py", line 593, in run
    self._callTestMethod(testMethod)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/async_case.py", line 65, in _callTestMethod
    self._callMaybeAsync(method)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/async_case.py", line 88, in _callMaybeAsync
    return self._asyncioTestLoop.run_until_complete(fut)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
    self.run_forever()
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
    self._run_once()
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 1854, in _run_once
    event_list = self._selector.select(timeout)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/selectors.py", line 469, in select
    fd_event_list = self._selector.poll(timeout, max_ev)
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/__main__.py", line 18, in <module>
    main(module=None)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/main.py", line 101, in __init__
    self.runTests()
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/main.py", line 271, in runTests
    self.result = testRunner.run(self.test)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/runner.py", line 176, in run
    test(result)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/suite.py", line 122, in run
    test(result)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/suite.py", line 122, in run
    test(result)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/suite.py", line 122, in run
    test(result)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/case.py", line 653, in __call__
    return self.run(*args, **kwds)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/async_case.py", line 160, in run
    self._tearDownAsyncioLoop()
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/unittest/async_case.py", line 126, in _tearDownAsyncioLoop
    loop.run_until_complete(self._asyncioCallsQueue.join())
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
    self.run_forever()
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
    self._run_once()
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 1854, in _run_once
    event_list = self._selector.select(timeout)
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/selectors.py", line 469, in select
    fd_event_list = self._selector.poll(timeout, max_ev)
KeyboardInterrupt
Exception ignored in: <bound method BaseEventLoop.call_exception_handler of <_UnixSelectorEventLoop running=False closed=False debug=True>>
Traceback (most recent call last):
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/asyncio/base_events.py", line 1771, in call_exception_handler
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 1463, in error
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 1577, in _log
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 1587, in handle
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 1649, in callHandlers
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 948, in handle
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 1182, in emit
  File "/home/john/.pyenv/versions/3.9.0/lib/python3.9/logging/__init__.py", line 1171, in _open
NameError: name 'open' is not defined

----------
components: asyncio
messages: 379931
nosy: asvetlov, jryan, yselivanov
priority: normal
severity: normal
status: open
title: Unexpected behaviour NameError: name 'open' is not defined
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 30 04:16:48 2020
From: report at bugs.python.org (Steven Yan)
Date: Fri, 30 Oct 2020 08:16:48 +0000
Subject: [New-bugs-announce] [issue42204] "import setuptools" Results in
 "ModuleNotFoundError: No module named '_distutils_hack'"
Message-ID: <1604045808.38.0.790448283251.issue42204@roundup.psfhosted.org>


Change by Steven Yan <Steven_Bot_Yan at 126.com>:


----------
components: Distutils
files: pic.png
nosy: dstufft, eric.araujo, sy
priority: normal
severity: normal
status: open
title: "import setuptools" Results in "ModuleNotFoundError: No module named '_distutils_hack'"
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49550/pic.png

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

From report at bugs.python.org  Fri Oct 30 05:16:03 2020
From: report at bugs.python.org (waicalibre)
Date: Fri, 30 Oct 2020 09:16:03 +0000
Subject: [New-bugs-announce] [issue42205] Add image/webp to list of
 non-standard mimetypes
Message-ID: <1604049363.03.0.933855009454.issue42205@roundup.psfhosted.org>


New submission from waicalibre <waicailbre_aayx at protonmail.com>:

WebP is an open-source image format that isn't included in Python's mimetypes. It hasn't been added because it has no IANA registration: https://bugs.python.org/issue38902

In mimetypes.py there is a list of common but non-standard media types that only match if strict=0 flag is given to the API methods. If WebP isn't going to be added to the big standard list, it could be added to the non-standard list.

----------
components: Library (Lib)
messages: 379940
nosy: waicalibre
priority: normal
severity: normal
status: open
title: Add image/webp to list of non-standard mimetypes

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

From report at bugs.python.org  Fri Oct 30 06:09:19 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 30 Oct 2020 10:09:19 +0000
Subject: [New-bugs-announce] [issue42206] Pegen: Raise errors occurred by
 the AST validator
Message-ID: <1604052559.69.0.261468356002.issue42206@roundup.psfhosted.org>


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

When working on the AST validator, it is unclear that which of the changes caused parser to fail on valid input. I propose to propagate the error and raise it.

Current:
$ ./python t.py
python: Parser/pegen.c:1146: _PyPegen_run_parser: Assertion `PyAST_Validate(res)' failed.

Proposed:
$ ./python t.py
ValueError: Test AST error raised by the Python/ast.c

----------
components: Interpreter Core
messages: 379941
nosy: BTaskaya, gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Pegen: Raise errors occurred by the AST validator

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

From report at bugs.python.org  Fri Oct 30 10:45:04 2020
From: report at bugs.python.org (serge-sans-paille)
Date: Fri, 30 Oct 2020 14:45:04 +0000
Subject: [New-bugs-announce] [issue42207] Python 3.9 testing fails when
 building with clang and optimizations are enabled
Message-ID: <1604069104.85.0.435616508554.issue42207@roundup.psfhosted.org>


New submission from serge-sans-paille <serge.guelton at telecom-bretagne.eu>:

How to reproduce:

```
git clone https://github.com/python/cpython && cd cpython
mkdir -p _build/optimized
cd _build/optimized
../../configure --enable-optimizations CC=clang
make
cd ..
./optimized/python -m test.regrtest -wW --slowest -j0 --timeout=1800 2>&1 | grep "error: Could not read profile code.profclangd"
```

This bug no longer happens on master branch because it's related to test_peg_generator.

----------
components: Build
messages: 379972
nosy: serge-sans-paille
priority: normal
severity: normal
status: open
title: Python 3.9 testing fails when building with clang and optimizations are enabled
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 30 10:57:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2020 14:57:17 +0000
Subject: [New-bugs-announce] [issue42208] Using logging or warnings during
 Python finalization does crash Python
Message-ID: <1604069837.91.0.668538321247.issue42208@roundup.psfhosted.org>


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

If you apply attached logging.patch, Python crash using attached crash.py:

$ echo|./python -i crash.py
>>>
>>> 
python: Python/_warnings.c:872: setup_context: Assertion `globals != NULL' failed.
Abandon (core dumped)


Attached logging.patch is a fix for bpo-26789: logging.FileHandler keeps a reference to the builtin open() function.

Attached crash.py does crash because of an unclosed file. It happens after PyInterpreterState_Clear(), in finalize_interp_clear():

    /* Last explicit GC collection */
    _PyGC_CollectNoFail();

setup_context() of Python/_warings.c does crash because tstate->interp->sysdict is NULL at this point.

Moreover, _io.TextIOWrapper.__init__() fails to import the locale module (to call locale.getpreferredencoding(), since the encoding is None) and picks the "ascii" encoding.

Moreover, even if I work around all these issues, _warnings.showwarnings() logs "lost sys.stderr" into stderr because, again, tstate->interp->sysdict is NULL at this point (and so sys.stderr no longer exists).

It looks like a bug in finalize_interp_clear() which triggers a garbage collection, whereas Python is no longer usable.

--

The logging module does automatically close files at exit using:

   atexit.register(shutdown)

But crash.py, a new file is opened by a logging handler after logging.shutdown() is called. Maybe another problem is that the logging module does not clear logger handlers, or prevent handlers to log more message, after shutdown() is called.

----------
components: Interpreter Core
files: logging.patch
keywords: patch
messages: 379974
nosy: vstinner
priority: normal
severity: normal
status: open
title: Using logging or warnings during Python finalization does crash Python
versions: Python 3.10
Added file: https://bugs.python.org/file49553/logging.patch

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

From report at bugs.python.org  Fri Oct 30 11:29:34 2020
From: report at bugs.python.org (gKuhn)
Date: Fri, 30 Oct 2020 15:29:34 +0000
Subject: [New-bugs-announce] [issue42209] Incorrect line reported in syntax
 error
Message-ID: <1604071774.71.0.0589140009748.issue42209@roundup.psfhosted.org>


New submission from gKuhn <gregorykuhn at gmail.com>:

Attempting to parse the following python code results in a fairly unhelpful syntax error along with an incorrect line number being reported:

    #a dodgy f-string

    def dodgy(**kwargs):
        print(f"{**kwargs}")

The result:

  File "<fstring>", line 1
    (**kwargs)
     ^
SyntaxError: invalid syntax


$ python -VV
Python 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:43:08) [MSC v.1926 32 bit (Intel)]

----------
messages: 379977
nosy: gkuhn
priority: normal
severity: normal
status: open
title: Incorrect line reported in syntax error
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 30 12:04:29 2020
From: report at bugs.python.org (Sree)
Date: Fri, 30 Oct 2020 16:04:29 +0000
Subject: [New-bugs-announce] [issue42210] float.hex discards sign from -nan
Message-ID: <1604073869.82.0.718371202647.issue42210@roundup.psfhosted.org>


New submission from Sree <sree314 at gmail.com>:

float.hex(float.fromhex("-nan")) returns 'nan'.

PyOS_double_to_string seems to check only if it is a NaN, but ignores the sign (unlike its handling of inf a few lines below):

<https://github.com/python/cpython/blob/e9e7d284c434768333fdfb53a3663eae74cb995a/Python/pystrtod.c#L903>

Issue 5981 (https://bugs.python.org/issue5981) added the ability for fromhex to recognize -nan, but hex should probably have been updated at the same time.

Encountered when testing float implementations.

----------
components: Interpreter Core
messages: 379979
nosy: sree314
priority: normal
severity: normal
status: open
title: float.hex discards sign from -nan
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct 30 12:56:11 2020
From: report at bugs.python.org (Soham Badame)
Date: Fri, 30 Oct 2020 16:56:11 +0000
Subject: [New-bugs-announce] [issue42211] CRASH
Message-ID: <1604076971.85.0.802956431757.issue42211@roundup.psfhosted.org>


New submission from Soham Badame <badamesoham8 at gmail.com>:

If you apply attached logging.patch, Python crash using attached crash.py:

$ echo|./python -i crash.py
>>>
>>> 
python: Python/_warnings.c:872: setup_context: Assertion `globals != NULL' failed.
Abandon (core dumped)


Attached logging.patch is a fix for bpo-26789: logging.FileHandler keeps a reference to the builtin open() function.

Attached crash.py does crash because of an unclosed file. It happens after PyInterpreterState_Clear(), in finalize_interp_clear():

    /* Last explicit GC collection */
    _PyGC_CollectNoFail();

setup_context() of Python/_warings.c does crash because tstate->interp->sysdict is NULL at this point.

Moreover, _io.TextIOWrapper.__init__() fails to import the locale module (to call locale.getpreferredencoding(), since the encoding is None) and picks the "ascii" encoding.

Moreover, even if I work around all these issues, _warnings.showwarnings() logs "lost sys.stderr" into stderr because, again, tstate->interp->sysdict is NULL at this point (and so sys.stderr no longer exists).

It looks like a bug in finalize_interp_clear() which triggers a garbage collection, whereas Python is no longer usable.

--

The logging module does automatically close files at exit using:

   atexit.register(shutdown)

But crash.py, a new file is opened by a logging handler after logging.shutdown() is called. Maybe another problem is that the logging module does not clear logger handlers, or prevent handlers to log more message, after shutdown() is called.

----------
messages: 379984
nosy: badamesoham8
priority: normal
severity: normal
status: open
title: CRASH
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 30 13:22:37 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 30 Oct 2020 17:22:37 +0000
Subject: [New-bugs-announce] [issue42212] Check if generated files are
 up-to-date in Github Actions
Message-ID: <1604078557.08.0.656569996113.issue42212@roundup.psfhosted.org>


Change by Filipe La?ns <lains at riseup.net>:


----------
nosy: FFY00, vstinner
priority: normal
severity: normal
status: open
title: Check if generated files are up-to-date in Github Actions

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

From report at bugs.python.org  Fri Oct 30 17:44:11 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 30 Oct 2020 21:44:11 +0000
Subject: [New-bugs-announce] [issue42213] Get rid of cyclic GC hack in
 sqlite3.Connection and sqlite3.Cache
Message-ID: <1604094251.24.0.415072580215.issue42213@roundup.psfhosted.org>


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

Get rid of the `pysqlite_Cache->decref_factory` hack by implementing proper support for cyclic garbage collection.

----------
components: Library (Lib)
messages: 379998
nosy: berker.peksag, erlendaasland
priority: normal
severity: normal
status: open
title: Get rid of cyclic GC hack in sqlite3.Connection and sqlite3.Cache
type: resource usage
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 30 18:05:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2020 22:05:31 +0000
Subject: [New-bugs-announce] [issue42214] Parser/pegen.c:68:
 _PyPegen_check_barry_as_flufl: Assertion `t->type == NOTEQUAL' failed
Message-ID: <1604095531.24.0.280205642021.issue42214@roundup.psfhosted.org>


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

When Python is built in debug mode, it fails with an assertion error on the following code:
---
def func1():
    if a != b:
        raise ValueError

def func2():
    try
        return 1
    finally:
        pass
---

Try attached pgen_bug.py:

$ ./python pgen_bug.py 
python: Parser/pegen.c:68: _PyPegen_check_barry_as_flufl: Assertion `t->type == NOTEQUAL' failed.
Abandon (core dumped)

----------
components: Interpreter Core
files: pgen_bug.py
messages: 380002
nosy: gvanrossum, lys.nikolaou, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Parser/pegen.c:68: _PyPegen_check_barry_as_flufl: Assertion `t->type == NOTEQUAL' failed
versions: Python 3.10
Added file: https://bugs.python.org/file49555/pgen_bug.py

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

From report at bugs.python.org  Fri Oct 30 20:11:40 2020
From: report at bugs.python.org (Rangel Reale)
Date: Sat, 31 Oct 2020 00:11:40 +0000
Subject: [New-bugs-announce] [issue42215] urlparse with a Windows path
 returns the drive name as the scheme
Message-ID: <1604103100.11.0.415033865754.issue42215@roundup.psfhosted.org>


New submission from Rangel Reale <rangelspam at gmail.com>:

Passing a Windows path to urllib.parse.urlparse, without file://, makes it detect the drive as the scheme even it having '\' after the ':', which makes it completelly wrong for a url.

Probably this function shouldn't be used with non-uri paths, but it shouldn't return a result that is so wrong as this. I think at least it should return the same input string if the url doesn't start with ://.


Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)] on win32
from urllib.parse import urlparse
urlparse('M:\\prog\\tests\\python\\json-ref-dict\\tests/schemas/master.yaml')
Out[3]: ParseResult(scheme='m', netloc='', path='\\prog\\tests\\python\\json-ref-dict\\tests/schemas/master.yaml', params='', query='', fragment='')
str(urlparse('M:\\prog\\tests\\python\\json-ref-dict\\tests/schemas/master.yaml'))
Out[4]: "ParseResult(scheme='m', netloc='', path='\\\\prog\\\\tests\\\\python\\\\json-ref-dict\\\\tests/schemas/master.yaml', params='', query='', fragment='')"
urlparse('M:\prog\tests\python\json-ref-dict\\tests/schemas/master.yaml')
Out[5]: ParseResult(scheme='m', netloc='', path='\\prog\tests\\python\\json-ref-dict\\tests/schemas/master.yaml', params='', query='', fragment='')

----------
components: Windows
messages: 380018
nosy: paul.moore, rangelspam, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urlparse with a Windows path returns the drive name as the scheme
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 30 20:36:15 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 31 Oct 2020 00:36:15 +0000
Subject: [New-bugs-announce] [issue42216] Optimize dict.popitem() & insert
 use case.
Message-ID: <1604104575.27.0.467151062817.issue42216@roundup.psfhosted.org>


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

PyDict_DelItem stores DUMMY entry in the hash table. Without DUMMY, collision chain will be broken so proving will be not working.

But `dict.popitem()` returns the last item in the insertion order. The item must be the last item of collision chain too.
So `dict.popitem()` can use EMPTY entry instead of DUMMY, and reduce dict resizing.

----------
components: Interpreter Core
messages: 380022
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize dict.popitem() & insert use case.
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 31 03:50:02 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 31 Oct 2020 07:50:02 +0000
Subject: [New-bugs-announce] [issue42217] compiler: merge co_code and
 co_lnotab
Message-ID: <1604130602.05.0.173247705477.issue42217@roundup.psfhosted.org>


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

co_consts are merged already, but I forget about code attributes other than co_consts.
Duplication ratio is vary by code style, but in case of logging, we can reduce 25% of them.

```
>>> data = open('Lib/logging/__pycache__/__init__.python-310.pyc', 'rb').read()
>>> import marshal
>>> x = []
>>> def walk(c):
...     x.append(c.co_code)
...     x.append(c.co_lnotab)
...     for cc in c.co_consts:
...         if hasattr(cc, 'co_code'):
...             walk(cc)
...
>>> code = marshal.loads(data[16:])
>>> walk(code)
>>> len(x)
336
>>> len(set(x))
249
>>> 249/336
0.7410714285714286
```

----------
components: Interpreter Core
messages: 380045
nosy: methane
priority: normal
severity: normal
status: open
title: compiler: merge co_code and co_lnotab
type: resource usage
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 31 07:16:42 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Sat, 31 Oct 2020 11:16:42 +0000
Subject: [New-bugs-announce] [issue42218] SystemError in compile builtin
 function
Message-ID: <1604143002.46.0.930999995617.issue42218@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

In Python 3.9.0, running

    compile('A.\u018a\\ ', '<string>', 'single')

raises

    SystemError: <built-in function normalize> returned a result with an error set

This is obviously invalid syntax, but it would still be nice to raise SyntaxError for that and the SystemError may be symptomatic of a bug.  Unfortunately I have no insight to offer beyond this hand-minimised reproducer :-/

----------
components: Interpreter Core
messages: 380053
nosy: Zac Hatfield-Dodds
priority: normal
severity: normal
status: open
title: SystemError in compile builtin function
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 31 10:46:55 2020
From: report at bugs.python.org (Akshay.Gupta)
Date: Sat, 31 Oct 2020 14:46:55 +0000
Subject: [New-bugs-announce] [issue42219] Typo in comment of listobject.h
Message-ID: <1604155615.24.0.944991659801.issue42219@roundup.psfhosted.org>


New submission from Akshay.Gupta <akshay.j398p at gmail.com>:

There is a typo in comment of _PyList_Cast(op) macro.
It should say 'PyListObject*' instead of 'PyTupleObject*'.

----------
assignee: docs at python
components: Documentation
messages: 380070
nosy: akshayj398p, docs at python
priority: normal
severity: normal
status: open
title: Typo in comment of listobject.h
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 31 12:02:56 2020
From: report at bugs.python.org (Andrew)
Date: Sat, 31 Oct 2020 16:02:56 +0000
Subject: [New-bugs-announce] [issue42220] Argparse: wildcards processing
Message-ID: <1604160176.59.0.918392301984.issue42220@roundup.psfhosted.org>


New submission from Andrew <andrew-aralov at yandex.ru>:

It's known that Linux and Windows shells process wildcards like '*' and '?' differently. Linux shell usually expands wildcards so the application gets list of files. In contrast, Windows passes the wildcards to application. So in cross-platform applications we have to expand wildcards manually only for windows. It may not be beautiful since it's usually not part of program's logic and seems kinda of arguments processing.
Could this problem be solved via adding optional functionality to argparse library? For instance some option 'expand_wildcards' in ArgumentParser constructor with default value False (in order to not break compatibility)?

----------
components: Library (Lib)
messages: 380076
nosy: Andrew
priority: normal
severity: normal
status: open
title: Argparse: wildcards processing
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/issue42220>
_______________________________________

From report at bugs.python.org  Sat Oct 31 12:16:40 2020
From: report at bugs.python.org (Daniel Alley)
Date: Sat, 31 Oct 2020 16:16:40 +0000
Subject: [New-bugs-announce] [issue42221] Potential memory leak in
 resize_compact() (for unicode objects)
Message-ID: <1604161000.37.0.700108867907.issue42221@roundup.psfhosted.org>


New submission from Daniel Alley <dalley at redhat.com>:

Disclaimer: I'm not familiar with the interpreter internals, nor am I really a C dev, so I could be misinterpreting these results due to inexperience.

I've been attempting to debug a memory leak which I thought was caused by a C API extension that we are using.  When running the unit tests for this library under valgrind, I get a couple of results like the following, where the bottom of the call stack is a realloc() triggered by _PyUnicodeWriter_Finish()

==5732== 76 bytes in 1 blocks are definitely lost in loss record 4,571 of 9,822
==5732==    at 0x4C2C291: realloc (vg_replace_malloc.c:836)
==5732==    by 0x4F52323: _PyUnicodeWriter_Finish (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4F5A087: PyUnicode_FromFormatV (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4F937BC: PyErr_FormatV (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4F93433: PyErr_Format (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4F836B9: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4F87C9E: PyEval_EvalCodeEx (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4EF6DE2: ??? (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0x4EDEF62: PyObject_Call (in /usr/lib64/libpython3.6m.so.1.0)
==5732==    by 0xF9785EF: c_warningcb (in /usr/local/lib/pulp/lib/python3.6/site-packages/createrepo_c/_createrepo_c.so)
==5732==    by 0xF98F897: cr_xml_parser_warning (in /usr/local/lib/pulp/lib/python3.6/site-packages/createrepo_c/_createrepo_c.so)
==5732==    by 0xF98B59E: cr_start_handler (in /usr/local/lib/pulp/lib/python3.6/site-packages/createrepo_c/_createrepo_c.so)

There is no explicit call to realloc() in that function, but there is a call to resize_compact(), which in turn calls PyObject_Realloc(). I assume all those are getting inlined which is why it looks like there's nothing in-beteween -- if not, then maybe the leak is actually somewhere else.

The following is speculation given that I have limited understanding of interpreter workings.

In the version of Python I am using (3.6), resize_compact() has some code that looks suspicious to me: [0]

Two things jump out: 

1) "_Py_ForgetReference(unicode)", which according to this mailing list email [1] is used "to avoid having the deallocator run as result of the
DECREF".  The definition and usage of "_Py_ForgetReference(unicode)" in newer versions of Python is hidden behind "#ifdef Py_TRACE_REFS" flags [2], but it was not being done previously, which raises the question if perhaps it was being used improperly in previous versions. Forgetting about an object without deallocating it would certainly cause a leak.

2) When comparing [0] to a nearly identical piece of code meant for resizing bytestrings [3], I notice that in the branch handling the out of memory case, the bytestring version calls "PyObject_Del()" whereas the unicode version calls "_Py_NewReference()".

Can someone with more knowledge take a look at this?  And if neither of these are "the problem" then perhaps help me investigate what might be causing this Valgrind output?


[0] https://github.com/python/cpython/blob/3.6/Objects/unicodeobject.c#L943-L952

[1] https://www.mail-archive.com/python-dev at python.org/msg108525.html

[2] https://github.com/python/cpython/pull/18332/files#diff-34c966e7876d6f8bf801dd51896327e4f68bba02cddb95fbf3963f0b2e39c38aR1043-R1045

[3] https://github.com/python/cpython/blob/3.6/Objects/bytesobject.c#L3006-L3015

----------
components: Interpreter Core
messages: 380077
nosy: dralley
priority: normal
severity: normal
status: open
title: Potential memory leak in resize_compact() (for unicode objects)
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct 31 13:27:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Oct 2020 17:27:12 +0000
Subject: [New-bugs-announce] [issue42222] Modernize integer test/conversion
 in randrange()
Message-ID: <1604165232.15.0.0916383458838.issue42222@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Move the int(x)==x test and conversion into the C code for operator.index().

----------
components: Library (Lib)
messages: 380082
nosy: rhettinger, serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: Modernize integer test/conversion in randrange()
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 31 18:11:50 2020
From: report at bugs.python.org (Austin Green)
Date: Sat, 31 Oct 2020 22:11:50 +0000
Subject: [New-bugs-announce] [issue42223] List repetition operator gives
 unexpected results
Message-ID: <1604182310.98.0.376819106818.issue42223@roundup.psfhosted.org>


New submission from Austin Green <austin.green at orcon.net.nz>:

Not sure if this is a bug, cannot find any clarification in the documentation.  Please reassign it if need be.

Using the * operator to generate a list of lists:
>>> a = [[0]*3]*3
>>> a
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
gives a list of 3 lists of zeroes, as expected.
But the data values appear to be shared, so e.g.
>>> a[1][1] = 'spam'
>>> a
[[0, 'spam', 0], [0, 'spam', 0], [0, 'spam', 0]]
Not what I was expecting!

A list comprehension gives the results I wanted:
>>> a = [[0 for x in range(3)] for x in range(3)]
>>> a
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
Looks just the same, but:
>>> a[1][1] = 'spam'
>>> a
[[0, 0, 0], [0, 'spam', 0], [0, 0, 0]]
gives a different result, and is actually what I was expecting from the first example.

----------
components: Interpreter Core
messages: 380101
nosy: austin.green
priority: normal
severity: normal
status: open
title: List repetition operator gives unexpected results
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct 31 18:39:36 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 31 Oct 2020 22:39:36 +0000
Subject: [New-bugs-announce] [issue42224] test_format:test_locale fails when
 locale does not set grouping in thousands
Message-ID: <1604183976.7.0.233218767398.issue42224@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

test_format:test_locale tests for the existence of the thousands separator in a formatted number.

However, my locale does not expect/enforce (not sure what the correct term is) grouping the number in thousands, which leads to the test (and consequently the whole test suite) failing:

?  cpython git:(test-format-locale-fix) ./python                  
Python 3.10.0a1+ (heads/master:3bf0d02f28, Oct 31 2020, 22:42:09) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, '')
'LC_CTYPE=en_US.UTF-8;LC_NUMERIC=el_GR.UTF-8;LC_TIME=el_GR.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=el_GR.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=el_GR.UTF-8;LC_NAME=el_GR.UTF-8;LC_ADDRESS=el_GR.UTF-8;LC_TELEPHONE=el_GR.UTF-8;LC_MEASUREMENT=el_GR.UTF-8;LC_IDENTIFICATION=el_GR.UTF-8'
>>> format(123456789, 'n')
'123456789'
>>> locale.localeconv()['grouping']
[]

I guess the fix here is to check whether grouping is empty or not in test_locale.

----------
components: Tests
messages: 380104
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: test_format:test_locale fails when locale does not set grouping in thousands
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 31 23:17:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Nov 2020 03:17:12 +0000
Subject: [New-bugs-announce] [issue42225] Tkinter hangs or crashes when
 displaying astral chars
Message-ID: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>


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

On my macOS Mohave, 3.10, echoing '\U0001####' (# = hex digit) or chr(#####) (decimal digits) in IDLE's shell either prints an error box or hangs.  On #13153, freezing on macOS was reported for 3.7.6.  Until tkinter on Mac works better, we should try to get an error box for all astral chars.

For an SO questioner with Ubuntu 18.04, now updated to 20.04 with python 3.8.6, some chars display (128512-128547; 128549-128555; 128557-128576, example chr(128516)) and some 'crash' (example chr(128077)).  I am trying to get 'crash' narrowed down and the tk version Ubuntu uses.
Serhiy, does >>> chr(128516) echo thumbs up on your Linux?

The SO crash example works for me on Windows.  I should test more codepoints.

----------
components: Tkinter, Unicode, macOS
messages: 380112
nosy: ezio.melotti, ned.deily, ronaldoussoren, serhiy.storchaka, terry.reedy, vstinner
priority: normal
severity: normal
stage: test needed
status: open
title: Tkinter hangs or crashes when displaying astral chars
type: behavior
versions: Python 3.10

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